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ABSTRACT 



The Shipyard Management Information System is a computer-based 
system that processes data on virtually every element of opera- 
tions within a United States Naval Shipyard. This thesis 
examines the characteristics and objectives of a general manage- 
ment information system and the philosophies of the Shipyard 
Management Information System as envisioned by the Naval Sea Sys- 
tems Command. 

The motivations for, and the characteristics of, distributed 
processing as they apply to management information systems are 
presented. It will be shown how an effective distributed data 
processing system can be created from selective addition of equip- 
ment to, and purposeful personnel reorganization of, the data 
processing configuration at Mare Island Naval Shipyard. 
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I. MANAGEMENT INFORMATION SYSTEMS 



AND DISTRIBUTED PROCESSING 

A. MANAGEMENT INFORMATION SYSTEMS 

Managers must have complete, accurate, and timely information 
available in order to make sound business decisions. A schematic model 
of the relationship between an information system for managers, a 
management information system, and a production system is shown in 
figure 1. As demonstrated by this model, the management information 
system measures attributes of the production system, processes the data, 
and prepares management information reports. In reality, the manage- 
ment information system is a part of the control loop that maintains 
dynamic control over the enterprise. The purpose of this section is 
threefold: to provide a working definition of a management information 

system; to delineate its general characteristics; and, to list common 
objectives of management information systems. 

1 . Significance of a Management Information System 

Every business enterprise has a management information system 
(MIS), however simple it may be. In a two-man partnership in which one 
man handles production and the other handles sales, each informs the 
other of developments affecting his own area of the operation. Thus, 
the firm has an adequate MIS, even if the primary vehicle is oral 
communication. In a slightly larger enterprise, the management infor- 
mation system may consist of manually prepared records and reports used 
to control and plan the business. The next level is the use of basic 
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Figure 1 INFORMATION/PRODUCTION SYSTEM RELATIONSHIP 
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mechanical equipment to lessen the record-keeping burden and to increase 
its effectiveness. This equipment may include bookkeeping machines, 
calculators, and accounting machines. Larger companies require a 
higher level of both equipment and procedural sophistication. These 
companies may have a very large computer processor connected to remote 
field offices, plants, and headquarters by high-speed teleprocessing 
equipment. The computer complex may record business transactions as 
they take place, analyze them, feed required support information to all 
related areas, and service inquiry activity concerning all of the 
stored transactions. At this end of the MIS spectrum, the operation is 
expensive, involving an annual monetary outlay in the million-dollar 
cost bracket. The tailoring of the system to the user's real needs 
becomes a critical and complex task. Meeting the information needs of 
management with a poorly conceived system which is either too weak for 
proper response, or too powerful, and thus too costly, can lead to 
disaster for the user. Additionally, the use of an advanced information 
system may determine management's ability to survive in a growth environ- 
ment. An effective MIS is critical to all business enterprises. With- 
out it, growth is inhibited, and paper work may very well strangle the 
enterprise. 

2. MIS Defined 

In most discussion articles, books, seminars, and even univer- 
sity courses concerned with management information systems, there is an 
initial difficulty in proceeding to the components of an MIS because 
there is considerable controversy as to the definition of a management 
information system. Sherman Blumenthal has created a sixteen-part 
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definition of a mangement information system [1] in which a primitive 
concept (such as: "datum - an uninterpreted raw statement of fact") 

is defined, and progressively more complex concepts are explained in 
terms of the simpler, previously clarified ones until a management 
information system is ultimately defined as consisting of parts of 
operational functions: "A management information system is an opera- 

tional function whose parts, corresponding to functional units, are 
information subsystems of other operational functions." A management 
information system becomes alternately definable as an operational 
function whose parts are the management control modules (that part of 
the information subsystem which supports the management control centers 
of an operational function) and operational control modules (that part 
of an information subsystem supporting functional units of an opera- 
tional function) of other operational functions. This rather imposing 
synopsis is neither meaningful nor universally applicable. 

The Instruction which promulgates the instructions and proce- 
dures for the operation and control of the Shipyard Management Informa- 
tion System at Mare Island Naval Shipyard, NAVSHIPYDMAREINST 5260. IB 
of 2 November 1-978 [2], specifically defines a management information 
system as: 

The combination of personnel efforts, forms, formats, 
instructions, procedures, data, information and communi- 
cation facilities related to automatic data processing 
equipment which providesan organized and interconnected 
means (either automated, manual, or a combination of 
these) for recording, collecting, transmitting, proces- 
sing, and displaying information in support of the 
functions of planning, directing and controlling the 
management of an activity as performed by an operational 
level therein. 
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This definition, while certainly specific enough for the management 
information system at Mare Island Naval Shipyard, cannot be universally 
applied because it is too restrictive. 

After analyzing numerous descriptions, applications, character- 
istics, and attributes of management information system definitions, 
the following synthesis, as proposed by Walter Kennevan [3], shall 
serve as the basic definition of an MIS for this presentation: 

A management information system is an organized method of 
providing past, present and projection information relating 
to internal operations and external intelligence. It supports 
the planning, control and operational functions of an organi- 
zation by furnishing uniform information in the proper time- 
frame to assist the decision-making process. 

This proposed definition of management information can be applied 

whether the underlying data are compiled, processed and disseminated 

by manual, mechanical, electro-mechanical or electronic methods. It 

is also applicable to all systems ranging from the least abstract to 

those which utilize the most sophisticated mathematical techniques. 

3. MIS Characteristics 



This definition of a MIS leads to the ten basic detailed chara- 
cteristics inherent in a management information system. These dis- 
tinguishing characteristics are that the system: (1) considers the 

full effect of a decision in advance by supplying complete, accurate, 
and timely data for use in the planning and decision-making processes; 
(2) eliminates from the planning and decision-making processes the 
problems associated with the use of inconsistent and incomplete data 
by providing a means for preparing and presenting information in a uni- 
form manner; (3) uses common data and methods in the preparation of 
long-range and short-term plans; (4) identifies, structures, and 
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quantifies significant past relationships, and forecasts future rela- 
tionships through the use of advanced mathematical techniques in analy- 
zing data, wherever it is appropriate to do so. 

Furthermore, the system must: (5) merge financial and pro- 

duction data, and all other pertinent data, to produce significant 
measures of performance to facilitate control of present costs, and to 
facilitate planning decisions with a minimum of data processing by 
utilizing standard data elements; (6) recognize the needs of all func- 
tional units so that the requirements of each are met with a minimum of 
duplication while serving the corporation as a whole; (7) reduce the 
time and volume of information required to make decisions by reporting 
to each level of management only necessary detail, and usually only the 
exception form the standard or norm; (8) utilize personnel and data 
processing equipment effectively so that the optimum in speed and accur- 
acy is achieved at the lowest possible cost; (9) require that the 
resulting information be presented to those responsible for the deci- 
sion-making and planning processes in a form which minimizes the need 
for analysis and interpretation; and (10), provide for system flexi- 
bility and adaptability to change. 

4. MIS Objectives 

In order to adequately specify the objectives of a management 
information system, the structure of an organization must itself be 
understood. This structure cannot be viewed as a static organization 
that is divided into divisions and departments, but as a dynamic, 
adaptable system. Within the organization, many processes take place 
in reaction to the present environment and in anticipation of the future 
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environment. These processes and flows, the resources needed to exe- 
cute them, and the distribution of managerial responsibilities needed 
to accomplish the required functions must be understood. Knowing 
these major forces affecting the nature of an organizational system 
enables one to translate the objectives of the entire organizational 
system into the MIS objectives to serve that organizational system. 

Since it is true that objectives of different types of organi- 
zations are normally different, it can be assumed that MIS objectives 
of these different types of organizations are also probably different. 
However, a common link for the management information systems of all 
types of organizations has been established as described by the seven 
general objectives delineated below [4]. For a specific organization, 
these general objectives may require modification in order to make them 
suitable to the needs of the specific organizational system concerned. 

The general MIS objectives are: integration of the six levels of a 

MIS; support of strategic organizational objectives; maintaining the 
primacy of managerial decisions over machine decisions; the automation 
of repetitive control functions; the streamlining of the adaptability 
process; keeping the management information system adaptable; and, 
keeping the MIS cost-effective. 

a. Integrate the Six MIS Levels 

The six levels of a MIS and the operational personnel asso- 
ciated with each level, as presented in figure 2, are: the four user 

oriented levels of planning (planners), control (supervisors), fore- 
casting (forecasters), and modeling (modelers); and the two technological 
levels of computing (computer specialists), and data administration (data 
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administrators). The managers, management specialists, and information 
specialists within these levels each employ different jargons, techni- 
ques, and data in the pursuit of their goals. Proper integration of an 
organization through the management information system allows each of 
these areas to interact with the system in its own terms, and to accom- 
plish its job in the most expeditious manner. At the same time, the 
MIS acts as a catalyst among these people of diverse skills, and enables 
them to work on a common project. 

b. Support Strategic Organizational Objectives 

Strategic objectives of an organization delineate expected 
achievements over a period of time. Strategic objectives become guide- 
lines for the development of plans for future operations. Strategic 
objectives are also guidelines for the tools required for the develop- 
ment, implementation, and assessment of plans. The MIS which is planned 
with the objective of supporting the strategic objectives of the organi- 
zation, will contain data that assists in the determination of specific 
types of problem areas and contain models that are appropriate to the 
forecasts and plans under development. The MIS will aggregate data in 
a manner allowing the planner, supervisor, forecaster, and modeler to 
do their best toward reaching the strategic objectives of the organi- 
zational system. 

c. Maintain Primacy of Managerial Decisions 

The purpose of any information system is to supply informa- 
tion to people so that they can make appropriate decisions based on 
information that is both timely and relevant. This implies that the 
primary job of a management information system is to aid people in the 
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solution of nonstructured problems which occur in the development of 
models that are essentially hypotheses about the organizational system 
to be tested and improved so that they eventually, within reason, 
resemble the actual nature of the organizational system. Nonstruc- 
tured problems occur in planning, where problem areas must be recognized, 
assumptions made, criteria defined, and alternatives evaluated. In the 
nonstructured problems, it becomes obvious that man must make decisions 
using the machine as his tool. The machine will do the tedious work of 
data searching, calculating, summarizing and comparing. Man, on the 
other hand, must do the creative work: deciding on a course of action, 

guiding the machine in its work, and evaluating the results produced by 
the machine. Thus, the manager makes the decisions, not the machine. 

d. Automate Repetitive Control Functions 

The MIS aids management in the solution of nonstructured 
problems by removing from the manager's concern much of the repetitive 
control functions. Since many control functions are highly structured, 
they are easily automated. This objective may appear to be contradictory 
to the previous objective - maintain primacy of management decisions 
over machine decisions. However, this is not so in that the intent of 
this objective is to automate the maintenance of the database and the 
comparisons of achieved status versus planned status, and to produce 
associated outputs. Decisions are not made by the machine, but by super- 
visory personnel who study these outputs. 

e. Streamline the Adaptability Process 

Adaptability is a very important characteristic of any 
enterprise. The organization must be able to recognize and react 
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rapidly to changes in technological and customer requirements. The 
management information system is able to streamline this adaptability 
process by employing three major practices: maintain extensive data 

about external factors which have historically affected the organiza- 
tion, and develop techniques which help identify new trends; maintain 
the control system in order to be able to ise it for comparison, but 
allow a planner to insert new goals with which to compare actual 
results; and, allow a manager to modify any model to include new fac- 
tors and then gather data to test that model . 

f. Keep the MIS Adaptable 

One of the best ways of enhancing organizational adapt- 
ability is to make the MIS itself adaptable. Although adaptable sys- 
tems do cost more to initially develop, design and install, the adapt- 
able system will not have to be redeveloped, redesigned or reinstalled. 
Future changes are relatively easily accomplished at a relatively small 
cost. Some of the capabilities for change that are included in the 
typical management information system are: changing of reports or 

reporting formats; changing methods of data entry or data base updating; 
modifying specific programs or models; increasing of storage capability 
by adding additional storage devices of higher capacity and/or speed, 
or replacement of present storage devices with newer ones of higher 
capacity and/or speed; and adding terminals to increase the number of 
time-sharing stations. 

g. Keep the MIS Cost-Effective 

The objective of MIS cost-effectiveness is to obtain the 
most effective system for the money spent. This can be done when all 
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other objectives of the organization are described in meticulous detail. 
Not only must organizational objectives be delineated, but the relation- 
ships between the MIS and organizational objectives must be clearly 
defined and thoroughly analyzed. An important result of this analysis 
is putting MIS objectives in priority order. Priority is determined 
primarily by the importance of the MIS objectives that support the 
objectives of the total enterprise. MIS objectives that support the 
highest priority organizational objectives are thus found at the top 
of the objectives list, and the lowest supportive objectives at the 
bottom. With such a priority analysis, the cost-effectiveness objec- 
tives are determined, and the management information system can be 
acquired that best satisfies them. 

B. DISTRIBUTED PROCESSING 

An objective of distributed processing systems is to reduce large 
data input bottlenecks as well as provide feedback of data necessary to 
run the enterprise. Distributed processing arose out of the need to 
get computer power where it is often needed - at the local level. A 
distributed processing approach gives local managers more control over 
and involvement with their computerized information systems and removes 
some of the processing burden from the central computing facility. A 
representative diagram of a distributed processing system is presented 
in figure 3. The purpose of this section is to present the motivations 
for, and the characteristics of, distributed processing as they apply 
to management information systems. 

1. Evolution 

Prior to the advent of real-time management information systems, 
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Figure 3 DISTRIBUTED PROCESSING SYSTEM 
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information systems emphasized historical data. These systems concen- 
trated on producing historic types of reports based upon today's defi- 
nition of yesterday's requirement. There was very little thought given 
to the production of relevant information for the control of concurrent 
operations or for future predictions of operating conditions. These 
systems were oriented toward custodial accounting, responsibility 
reporting, integrated data processing, and integrated management infor- 
mation systems [5]. 

Custodial accounting did not take into consideration a basic 
need of management - that of feedback to compare actual performance with 
the desired standard. Manual methods of bookkeeping along with punch 
cards were utilized to process data in a batch system. No attempt was 
made to integrate records. Historical reports required lengthy proces- 
sing time. Access of files was on a sequential basis. Data was pri- 
marily used for accounting purposes with output oriented information 
processing. In summary, a custodial accounting system performed its 
function slowly and with no great concern for the ability of data proces 
sing to aid in the decision-making process. 

The preparation of reports on the basis of responsibility assign 
ments evolved from the simple custodial accounting approach. The 
responsibility reporting system's orientation was toward the accumula- 
tion of historical data for a specified time period according to proce- 
dures determined by the various activities and levels of responsibility 
within an organization. It was concerned with activities that were 
directly controllable and accountable by a particular individual. 
Although this system made historical reports available more rapidly than 
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did the custodial accounting system, problems still occurred in that 
the responsibility accounting system was narrow in its perspective. 

It failed to take into consideration other subsystems within the 
sphere of the organization - the integration of personnel, production, 
sales, and inventory, with accounting. 

The result of systems designers recognizing that there were 
more facets to an operation than just accounting, resulted in a logic- 
ally unified system known as an integrated processing system. Data 
that was entered into this system was entered singly, as before, but 
now became available for a multiplicity of uses which transcended 
organizational and functional boundaries. Elements within a processing 
activity that were related to other uses were combined into common 
coordinated procedures which were made possible by having the whole 
system interrelated. This integrated system was also flexible since 
the data controlling programs could usually be readily changed as 
opposed to retraining personnel in the use of new equipment and proce- 
dures. Although integration substantially reduced file duplication 
and allowed for the coordination of major functions with one another, 
optimum results were still not guaranteed. Control of current opera- 
tions and the facilities of managerial functions, through a better 
reporting system, was needed. 

An integrated management information system improved upon 
several of the deficiencies of the integrated data processing system 
by revising its basic concepts. This basic design provided for decision- 
oriented information to management that was utilized to assist in the 
planning, controlling, and evaluating of the activities of the 
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organization. Periodic reports became a secondary feature; information 
was used more for organizational control and it served several uses and 

ultimately reduced costs of obtaining essential reports. This integra- 
ted management system provided more than a mechanical link between 
various organizational functions; it provided an automatic means of 
performing routine decision-making tasks, thus freeing management to 
perform more complex tasks requiring human thought processes. One 

important deficiency of the integrated management system, however, was 

« 

that data had to be accumulated for a period of time before it could be 
processed. For this reason, all heretofore mentioned systems - custo- 
dial accounting, responsibility reporting, integrated data processing, 
and integrated management information systems - are termed backward- 
looking systems, since they observe past history before generating 
reports for feedback. A system that is oriented toward the present, 
and even the future, was needed - a forward-looking control system. 

A trend in information systems is the implementation of real- 
time information systems, often referred to as on-line real-time 
systems. Typical applications include hotel and airline reservations, 
stock market information, law enforcement intelligence, and hospital 
patient records. The overriding characteristic of this type of system 
is the on-line real-time concept in which data is sent directly into the 
computer for processing as soon as it is made available. The real- 
time aspect indicates that the data is processed into information and 
returned to the source, or some sort of an action station, sufficiently 
soon in order to effectively perform a controlling operation on the 
environment. In order to be effective, the real-time system must have 
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an integrated structure with a data oriented, as opposed to a functional 
or output oriented, data base since data acquired from one source will 
serve more than one functional area within the organization. The data 
base, then needs to be structured in order to satisfy the needs of 
management, contain fully identified elements in order to serve a vari- 
ety of purposes without an excessive amount of programming. One defi- 
ciency of a real-time system is its inability to provide the information 
desired by the top-level executives who are responsible and accountable 
for the full range of all of the organization's activities. Their 
principle task revolves around strategic planning activities. A 
real-time information system cannot provide long-range information 
as such. It can, however, respond with immediate feedback on present 
operations, which is necessary in order to modify plans. A more recent 
approach to real-time systems is distributed processing. 

2. Motivations for Distributed Processing 

In the evolutionary cycle of computing systems, there has been 
a tremendous dependency on one or more large central processing units 
to perform the variety of required data processing functions. Bottle- 
necks are created whenever large amounts of data are simultaneously 
presented to the same processing unit with resulting undue delays in 
information retrieval. Distributed processing was formulated as an 
antidote to that problem in that it has been postulated as being capable 
of focusing computing power to the location where it was most needed, 
at the lower levels of the organization. This leads to a system of 
decentralized executive control. This decentralized control allows for 
the positive influence of the systems design aspects of extensibility. 
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integrity, performance [6], and cost as motivational objectives for 
implementing a distributive processing scheme. 

a. Extensibility 

Extensibility is the degree to which a system's functions 
and performance can be altered without changing the system itself. 
Extensibility is also known by its synonyms of expandibility, flexi- 
bility, and adaptability. Major benefits of extensibility are ease of 
modification and ease of growth. 

In the sense of modification, extensibility refers to the 
ease of the replacement of a logical software function, or a hardware 
element without disturbing its relationships with other elements. 

Growth extensibility allows for low cost configurations, upgrading of 
functions and performance in small increments, and low corresponding 
incremental cost increase. 

The decentralized distributed system offers these improve- 
ments in extensibility over other systems since boundaries to perform- 
ance conditions are less likely, or at least less restrictive, than for 
centralized systems. It will thus be possible to specify a minimum and 
a maximum system size in conjunction with the number of permitted 
increments in order to achieve whatever performance level is desired. 
These increments may very well be incorporated without any changes in 
the hardware or software design - especially if they are prediced, and 
allowances made for them, in initial system design. 

b. Integrity 

The degree to which a system is able to tolerate faults, 
errors, and failures is known as its integrity. Integrity is also known 
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as fault tolerance, and reliability. A fault is an error generating 
defect in system mechanics or algorithms. Errors occur when good items 
of information are turned into failures by the normal algorithms of the 
system. A failure is an event at which the system violates its speci- 
fications. The integrity function involves isolation, diagnosis, and 
resource recovery techniques which are designed to prevent further 
damage and restore the system to a satisfactory operating status. 

Network resource sharing of a distributed processing system 
accomplishes the majority of integrity considerations. Decentralization 
of control also allows for fewer error-producing binding situations 
between processes and individual processing elements such as processors, 
memory and communication paths. Much interprocess communication becomes 
interprocessor communication as a result of decentralized control, this 
is beneficial from an integrity viewpoint in that detection and diagnosis 
is enhanced by the mutual cooperation of multiple processors enabling 
even difficult to discover errors of algorithm design to become more 
visible. 

c. Performance 

The most prevalent definition of performance is throughput 
or response time. A decrease in response time is experienced under 
centralized control when more processors are added to the system, so 
that an idle processor can immediately be activated to service a request 
without suspending other processing or having the request lounge in a 
queue waiting for service. Even greater benefits can be derived when 
many processors cooperate in a single job. 
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d. Cost-Effective 



Having several interconnected processors cooperating on one 
job is also more cost-effective than the utilization of one large proces- 
sor of equivalent performance. The quantity and functionality of the 
total smaller processor's logic systems is more readily agreeable to 
high levels of hardware unity than is that of the larger processor. The 
latest, most cost-effective technology can be employed in designing and 
implementing the smaller processors at a relatively rapid rate enabling 
them to begin functioning sooner than their larger counterparts. Since 
smaller processors are manufactured in larger quantities, they can bene- 
fit from production economies. 

3. Characteristics of Distributed Processing 

With an understanding of the need for and the motivational 
factors concerning distributed processing, several characteristics 
that delineate a system as being a "distributed processing system" 
need to be described. All of the following should be present to some 
degree in order to so designate a system: a physical distribution of 

components; multiplicity of components; a high-level operating system; 
system transparency; autonomy; an effective communications network; and 
a distributed data base system. 

a. Physical Distribution of Components 

The physical distribution phase of the components of a 
distributed processing system refers to the procedure whereby processors 
and other integral components of the system are physically separated 
from each other. This separation may be only by meters, as could be 
found in a manufacturing application located completely within the 
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confines of one building, or by thousands of kilometers as in the 
ARPANET application which has intercommunicating sites in Hawaii, the 
United States mainland, and in Europe. Descriptions that address 
physical separation of components as the only criteria for a distributed 
processing system, however, are completely erroneous. Although physical 
separation forms a part of the definition, a complete description must 
include the concepts under which physical distribution is in evidence, 
such as in the physical separation of processing hardware; however, these 
are not necessarily considered to be distributed processing systems, 
b. Multiplicity of Components 

A multiplicity of components indicates that the profusion of 
general-purpose integral parts of. the system, including both physical 
and logical resources, must be present to form a dynamic system. It is 
not required that the components be of uniform structure; however, they 
must be available to be assigned to specific tasks on a rotating basis. 
Basically, it is required that the system have the capability to be 
able to dynamically reconfigure its resources on a short-term basis in 
order to provide specific resource services at any specified time. Also, 
those elements within the system that are not involved specifically with 
the assignment, cannot have their normal operations affected in any way 
by virture of the several variations of interconnections throughout the 
system that may be permitted. The availability of these multiple 
resources and the capability to interconnect and utilize them effectively 
and efficiently are highly essential prerequisites for the objectives of 
extensibility, integrity, performance, and cost control [7]. 
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c. High-Level Operating System 

The design of a high-level operating system for the dis- 
tributed processing system is crucial since it must be concerned with 
several unique characteristics and problems. In order to properly 
gain access to the distributed network, the potential user not only 
must be familiar with the operating system of the equipment he is using, 
but the operating system of the remote equipment that is to be utilized 
for the job execution, as well as the overall system operational con- 
trols. This is virtually an impossible task due to the general incom- 
patibility of operating systems with each other. It is also a truism 
that information about the available resources and how to use them is 
difficult to obtain even for the individual who is willing to learn 
the specific sub-systems he will be using. Proper design of the global 
operating system of the distributed network will unify the diverse types 
of local operating systems, as far as the user is concerned, and present 
him with only one operating system. 

The development of a network operating system (NOS) as an 
integral part of a distributed processing system is thus essential. The 
NOS must be a collection of hardware and/or software designed to enable 
the interconnected computer system to be employed in a convenient, reli- 
able, and cost-effective manner. An effective network operating system 
is able to assist users to exploit the various resources available in 
the computer network in a manner analagous to the way in which a local 
operating system is able to provide a controlled access for its users to 
its restricted sphere of control. In principle, a NOS is able to pro- 
vide user services far greater in magnitude than an ordinary operating 
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system because of its "influence and connections" within the distri- 
buted system's multiplicity of resources. There is a potential for 
system degradation, however, if the network operating system places 
too high of a reliance on system components that are subject to failure, 
without the employment of an extensive back-up capability. The NOS 
must therefore be carefully designed so that it makes use of redundant 
equipment in the distributed system and not fall into the trap of 
inadvertently reducing, instead of increasing, system integrity. Other, 
currently active, processing nodes within the system would then be 
advantageously employed for system back-up upon notification by the 
network operating system when the need for such processing transfer is 
required. 

In a centralized, hierarchical processing system, the opera- 
ting system is assumed to have accurate and up-to-date information 
concerning its operational configuration at any specific moment in time. 
This may not necessarily be the case in a distributed processing con- 
figuration. In fact, it is highly unlikely that truely complete infor- 
mation will ever be available due to the inherent time delay in the 
collection of status information about the various system components. A 
conventional processor's operating system is able to request status 
information of a component and be assured of a reliable answer since 
that single operating system controls the activities of that single 
component. The operating system is thus assured that component status 
will not change until whatever decisions that are required concerning 
the interrogated componenthave been made. Due to the autonomy of the 
distributed system (to be amplified later), however, significant time 



36 



lags concerning status information undoubtedly will develop. Decisions 
of the NOS that concern a specific device may thus be made and returned 
too late to effectively alter the operating environment in the desired 
manner. Inaccurate information begets inaccurate decisions which beget 
inaccurate actions - a vicious circle that has the potential of negating 
any benefits of the distributed system. 

To further complicate the picture, the possibility exists 
that different status information will be presented to the different 
system controlling devices. These variances may occur as a result of 
time delays in the transmission of status information, the intentional 
or unintentional shielding of information from the various controllers, 
or a hideous combination of the two. Network operating systems designers 
must have, therefore, considered the possibilities of designing the NOS 
to accept and work with an error filled, inaccurate system status infor- 
mation field. To further complicate matters, most proposed procedures 
for coping with time delay induced problems, such as voting and software 
synchronization, also need to be processed by the system which results 
in further, possibly catastrophic time delays [8]. 
d. System Transparency 

System transparency is that characteristic of the system 
that provides the user the illusion that he is receiving a set of 
processes and not processors. The user is able to request a specific 
service to be provided and not be concerned as to which specific 
serving device is being employed. The user is able to communicate with 
the system in the development of routines and programs as though he were 
using a single centralized system. Communication with the distributed 
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system is normally easier since the NOS software is routinely designed 
to interface with all the verities of devices, languages, and data 
definitions available within the system. Since the organization of 
the system and the knowledge of specific device employment are usually 
kept from the user, services are requested by name instead of by device. 
The previous discussion illustrates that a single-processing system 
could provide the user services if the requisite devices were available. 
However, the distributed system benefits of extensibility, integrity, 
and performance probably could not be provided under these conditions, 
e. Autonomy 

Autonomy of the distributed processing system is that attri- 
bute which allows personnel at the local operating level to develop much 
of their own data processing procedures without continued support and 
"guidance" from a central controlling station. This autonomy is 
reflected in both physical and logical operations. Physically, message 
transmission requires cooperation between both sender and receiver so 
that hardware operations can continue to perform their assigned trans- 
actions even though the centralized controller is temporarily unavail- 
able. Logically, the same degree of cooperation between processes must 
exist. Unique or critical processing can be handled at the local opera- 
ting level because of the ease of local program development. Operational 
activities peculiar to one operating system are able to be accomplished 
in the distributed environment due to this cooperative autonomy which 
results in overall systems flexibility. It must be emphasized that this 
autonomous virtue is not anarchical in nature. All systems components 
operate under a controlling set of procedures which is reflected in the 
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philosophy of the network operating system. In order to obtain the 
system benefits of extensibility, integrity, and performance, a high 
degree of autonomy is required. 

f. Effective Communication Network 

An interprocess communication scheme is an essential ingre- 
dient in the formulation of any computer network or operating system. 

A "link" can probably best be defined as a union of cooperating proces- 
ses. It is a general description of a logical communications path in 
a computer interconnection diagram. Link communications provide the 
following advantages: uniform communications are possible no matter 

what the physical separation or configuration may be; all communications 
are message, as opposed to signal, oriented; the link can be structured 
so that processes are identified by name or specified directly accord- 
ing to functional classification. Two basic types of link operations 
are needed - one to put messages into the link and another to remove 
them from the link. These two routine interprocess communications can 
be accomplished by the two system primitives, SEND and RECEIVE 
respectively. Their coordinated operation serves to insure that exces- 
sive length messages are not attempted to be terminated early, that 
proper receipt occurs, and processes waiting for the occurrence of the 
event are properly activated. Two additional coiraiunications primitives, 
the SUSPEND and RESTART primitives, allow for the special case situa- 
tions of interrupts occurring in normal operations to service a priority 
project. These two primitives will, respectively, suspend all activities 
of the member processes of the interrupted link until the priority 
project has been finished, and then reactivate the regular processing 
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at the point of suspension [9]. 

g. Distributed Data Base Management System 

Many users are granted access to vast ranges of information 
through the employment of a distributed data base management system 
which extends the capacities of computing systems [10]. The organiza- 
tion of the data in the distributed data base system is influenced by 
the overall function of the system itself, the geographical distribution 
of the data, and the designer's philosophy. As such, there are several 
classification schemes available. Geographical distribution of data 
and directories is one method. Another is by the amound of redundancy 
in which the data base is either partitioned or replicated. Partition- 
ing refers to the spreading of the data base over several computers, 
while a replicated system stores some portions of the data base dupli- 
cated at various storage nodes within the distributed network. 

(1) Redundancy . Partitioning usually involves the division 
of a very large and dynamic file among several back-end processors within 
a distributed system. A back-end processor is a computer that performs 
the data management functions for one or more different computers. Par- 
titioning increases data accessibility, but usually at the cost of more 
control and communications overhead than is experienced, obviously, with 
a single file system localized to a single computer. Efficient opera- 
tion of the NOS software is able to reduce this overhead, however. Redun- 
dancy is normally accomplished by locating specific files proximal to 
the machines that will most often employ them. This method is able to 
reduce the amount of required intermachine connections, often a limit- 
ing factor in the performance of a distributed data base system. Another 
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benefit of redundancy is that is provides for increased access to the 
multiple copies of the data, available back-up, and somewhat decreased 
communication time. Redundancy does impose the tradeoffs of additional 
cost due to increased storage requirements as well as the increased com- 
plexity in normal file updating. 

An additional problem experienced by both partitioned 
and replicated systems due to redundancy is encountered in the cata- 
loging function - information concerning the data base itself. The 
catalogue, often termed a directory, must be updated whenever a file is 
created or deleted, a major modification to a file description occurs, 
and whenever changes to user access permissions occur. This redundancy 
characteristic of a distributed system imposes additional cost and com- 
plexity factors in updating the catalogue due to: inherent communica- 

tions problems of a geographical ly distributed data base; the possibility 
of a broken connection to the main network from a node when operating in 
local mode which will be relected in out-of-date information for that 
node; and, similar problems that are encountered when there is distri- 
bution of the directories in addition to, or separate from, the data 
base. A highly efficient network control software system is required 
to correct the cataloging problem. This software must be able to moni- 
tor each node to ascertain when it has gone into a local operating mode 
and, upon completion of the operation, search it for transactions that 
may require updating of the system catalogue. A catalogue monitoring 
program or subroutine also needs to be resident so that each directory 
can be compared with every other directory to make certain each of them 
contains reliable information about the data base. Journalizing of 
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catalogue transactions may be necessary during peak operating periods 
in order to be certain that proper catalogue updates are made. 

(2) Data File Allocation . The allocation scheme for data 
files among the multiple physical storage devices available in the dis- 
tributed system is one of the problems requiring a solution by the 
database administrator in order to optimally employ all of the storage 
capability. In order to accomplish this task, information concerning 
real, or best-guess, utilization of files is required. It is very often 
the case that the behavior pattern of file employment is so dynamic that 
the scheme of file allocation must be inspected with a high frequency to 
make certain of a continuing optimal allocation scheme. The first step 
is to allocate files to the back-end processors, and then among the 
devices associated with each specific back-end processor. Parameters 
often associated with file allocation algorithms for a distributed data 
base management system include: the level of data sharing which indi- 

cates a partitioned or replicated sharing scheme and, if replicated, to 
what extent, the nature of the access patterns which may range from 
query only to extensive updating schemes; and, the information of the 
nature of the accesses themselves which may be deterministic, have a 
predictable outcome, or probabilistic, with varying outcomes. 

Normal file allocation schemes follow a cost-effective- 
ness analysis procedure. A generalized costing equation is developed 
and then various schemes are proposed and analyzed with the intention 
of minimizing that equation. Total cost is composed of the costs of 
updating, inquiry, and storage. Any allocation pattern that can reduce 
one or, preferably, more of these components is desired. Since both 
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the monitoring of file employment and the reallocation of files cost 
money in memory requirements and software utilization, as well as occupy- 
ing linkage paths, an optimal balance between the cost of a suboptimal 
allocation scheme and the cost of reallocation is desired. It becomes 
obvious that, in a distributed system, the cost of obtaining files 
residing at other than local network nodes is an important factor to 
consider. The proper balancing of storage, communication, and data 
base manipulation schemes is necessary to both reduce costs and enhance 
extensibility, integrity, and performance. 

4. Additional Advantages of Distributed Processing 

A large portion of the appeal of a distributed processing system 
is due to the hybrid approach it offers between the two extremes of the 
centralized and decentralized systems. It is possible for the distri- 
buted system to obtain the best balance between these two alternative 
types of basic configurations in order to obtain the desired functional 
requirement. Additional advantages of distributed processing systems 
can be summarized as follows: powerful processing for application which 

require a large machine, with full servicing capabilities provided by 
utilizing a central machine for gross processing services, with inputs 
and outputs transmitted through the interconnecting communications links. 
Overall system's efficiency is increased since, tasks for which a large 
processor is not well suited, such as on-line editing and interface 
inquiry, can be transferred to the distributed processors for action. 

Work can be shifted from an overloaded processor to one which 
has a lesser demand in order to reduce queue size during peak operating 
times; the central technical staff can support specialists assigned to 



43 



projects that are being performed at local processing sites; consoli- 
dation of programs and the sharing of common data which provides for 
system integration of information processing can be completed on the 
large control unit instead of on the local processors when it is deter- 
mined to be more cost-effective to do so; organizational activities can 
be integrated through the exchange of summary data through the organi- 
zational hierarchy; users are able to directly control and become more 
intimately involved with organizational activities in a distributed 
system; some processing nodes can be dedicated to perform specific 
processing services resulting in economies of specialization rather 
than attempting to have each node capable of performing all system ser- 
vices; relatively small sub-systems can result in simplification and 
additional economy, especially if a mini or micro styled computer is 
used for the local processing. 

Communication cost can be reduced along with the reduced volume 
of processing since much processing can be accomplished internal to the 
local processing units without going through a central machine; increased 
communications efficiency also reduces communications costs since full 
messages can be stored and then sent at off-peak periods as opposed to 
sending individual signals as they occur; response time is reduced when 
interactive functions are performed locally; reliability and security 
requirements are enhanced by local processing; the prediction and con- 
trol of costs of the central system can be more accurately accomplished 
through the use of dedicated processors for local functions; distributed 
processors are able to share common network software and data bases; 
central support services can be provided on an on-line real-time basis 
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as needed to the peripheral elements of the distributed system. 

5. Pitfalls to Distributed Processing 

Although a distributed processing system offers many advantages 
which were summarized above, there are several potential pitfalls which 
cannot be called distinct disadvantages, but nevertheless pose demon- 
stra table hazards to the full implementation of a distributed processing 
system [11]. There is, for instance, a tendency to add additional 
capabilities to the distributed processor until it almost becomes a 
system in itself. The specialized function that was initially intended 
for the local processor is slowly camouflaged by the incremental exten- 
sions employed, often under the guise of scale economy and low incremen- 
tal costs. The specialized node suddenly has evolved into the miniature 
general-purpose system alluded to, without the accompanying savings of 
scale normally realized. 

A distributed data base management system often is faced with 
the major problem of data incompatibility especially within systems 
composed of various software designs incorporated into a heterogeneous 
network. Variations in logical structures become the problem, and 
require a data base translation facility.. Structural and query transla- 
tions are the two major components necessary to be adequately solved in 
order to homogonize the data system. One method of improvement is to 
include a software package which expresses the relationships between 
source and target bases and contains a description of system data bases 
and a translational data definition language. 

Interesting security problems are posed by a distributed data 
base system. It would be beneficial to have the back-end processor 



45 



screen all requests to the data base. However, since there are no pro- 
grams resident within the back-end processor, it is impossible to moni- 
tor data base activity. A gigantic security liability is inherent in 
systems which rely on public communications facilities to distribute 
information, programs, et cetera, to geographically dispersed locations 
Current technology is able to easily monitor transmissions between 
these sites. One recommended solution is to rely upon encryption tech- 
niques to preserve security. 

Unnecessary system duplication is often encountered if each 
distributed system project group is allowed to proceed independently in 
the development of its processing node. Another hazard of independent, 
uncontrolled development is the possibility that programs and data 
developed under these conditions may be incompatibly structured for use 
by the systems. Additional problems within a distributed processing 
system can be summarized as follows: well-known techniques of systems 
and processes design may be violated by inept design practices utilized 
by inexperienced personnel that may be assigned to a local processing 
unit; development of a sub-process at the local usage level may induce 
degenerations within the overall system; and, excessive sophistication 
may be attempted unnecessarily which violates the simplicity aspect 
desired in a distributed processing system and causes exceedingly com- 
plex technical problems that may be difficult to correct. 

6. Guidelines For Development of a Distributed System 

Generalization of the guidelines to be used in the development 
and implementation of a distributed processing system are not particu- 
larly useful since each system is normally postulated to serve some 
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particular need which is defined by the specific purpose for which it 
is to be designed. Some general guidelines can be proposed, however, 
which are applicable across a wide range of circumstances and thus 
worthy of presentation: the structure of the system must be defined 

by the master plan. Since independent components evolve from the dis- 
tributed system, the master plan is an integral procedure to the 
development in order for each subsystem to focus its attention on 
where it belongs in the total scheme of things. Structurally , the 
system can be dimensioned along many different, or a combination of, 
dimensions such as geographical, commonality of processing functions, 
functional responsibilities and response time, 
a. Simplicity 

Significant advantages to a distributed system occur when the 
components are maintained as simply as the specifications of design will 
allow. System programs should follow the rules of structured design and 
be as uncomplicated as possible and still achieve desired results. Data 
structures need to be designed with transportabi 1 ity in mind. If each 
distributed component is limited to a narrow scope of functions, simpli- 
city is enhanced. Choosing a system structure that allows for a high 
degree of independence between the system components and the total sys- 
tem also results in an enhancement of simplicity. Increased independence 
is achieved by requiring relatively few links accessing each system com- 
ponent, and limited sharing of corraion data elements. Response time 
requirements for inter-component communication also influence system 
independence in that the longer the permitted response time, the greater 
the resulting independence. 
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Design tradeoffs occur in deciding whether to design for 
processing efficiency or cost-effectiveness. A relatively inexpensive 
system may not be optimum from a processing standpoing and vice-versa. 
Significant performance and cost variations may be encountered when 
balancing these two important facets of design in the cost-benefit 
analysis phase. There are no simple rules-of-thumb or shortcut proce- 
dures available to the designer. Careful analysis of each hardware or 
software performance proposal must be made against economic considera- 
tions and the consequence of each alternative solution internally weighed 
against all specifications before the designer selects a configuration 
for final implementation. 

b. Standardization 

Primary orientation of a central coordinating group, who is 
concerning itself with system design, is to ensure standardized communi- 
cations interfaces and adequate means for allocating and balancing sys- 
tems resources are obtained. The following list of matters also need to 
be attended to by this coordinating group: the provision of a central 

computing service; the development of integrated applications to be run 
on central facilities; the development of administrative functions 
orientated toward the system-wide data base; common application program 
development; acquisition of technical services to assist in the develop- 
ment of distributed applications; personnel training; budgetary review; 
hardware selection and approval; hardware maintenance requirements and 
vendor support; documentation standards; system security; and, priority 
use standards. 
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C. PHYSICAL SECURITY 



Two major categories of the physical security of a data processing 
site concern protection from unauthorized access to the computer instal- 
lation and necessary precautions to prevent accidental destruction of 
the files and data processing equipment [12]. Prevention methods 
employed to guard against unauthorized entry during normal working 
hours include: a receptionist at the entrance to the data processing 

and storage area; guard service; electric locks; a badge or other 
identification system; restricted entry policy; and, a pass system to 
authorize the entrance or exit of materials from the site. Protection 
methods to be employed after normal working hours include, but are not 
limited to: guard service including a roving patrol feature; door alarms 

installed and periodically tested; and, secure door locks in place and 
in use. 

Practices to be taken to detect and/or minimize destruction of equip- 
ment and files from disasters include protection methods for fire, water 
damage, and damage from external events. Fire protection methods encom- 
pass: charged fire extinguishers throughout the processing and storage 

areas and their periodic inspection; installation and testing of fire 
and smoke detection systems; emergency shutoff switches; and, strict 
enforcement of "No Smoking" practices. Water damage may be caused by 
a leaking roof, broken water pipes within the site, and sprinkler system 
operation. Protection from this sort of damage will entail installation 
of air conditioning, sprinkler system and building water shutoff valves 
for the installation, as well as nonflammable emergency equipment covers 
that are readily available and easily installed. Protection from external 
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events is enhanced by the lack of windows and other accesses from the 
exterior of the building. Existing accesses must be secured by iron 
grillwork and have secure window shutters available to protect the 
site from damage by hurricanes, wind storms, earthquakes, riots and 
other catastrophic events. 
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II. THE SHIPYARD MANAGEMENT INFORMATION SYSTEM 



A. INTRODUCTION 

Information flow within a typical naval shipyard has been placed in 
a critical position due to the often complex nature of work that is 
accomplished, the rapid response to and control of work required, as 
well as ever-increasing costs. In order to effectively manage over- 
hauls whose total budget may exceed $150 million annually, shipyard 
managers require reliable and timely information in order to enable them 
to make sound decisions concerning shipyard operations that are both 
mission and cost-effective. The Shipyard Management Information System 
(MIS) was developed for exactly that purpose; it provides the shipyard 
managers with rapid, accurate information to assist in the decision- 
making process which in turn enables the managers to control resource 
expenditure over the entire spectrum of shipyard operations. The Ship- 
yard MIS is able to provide the majority of the operational and pre- 
dictive information needed to monitor productivity [13], provided that 
the system is applied in the manner under which it was designed to 
operate. 

B. EVOLUTION 

The Shipyard Management Information System obviously did not suddenly 
appear as the answer to the shipyard manager's monitoring and control 
problems, but had to slowly evolve through a number of years and con- 
figurations. The origins of the Shipyard MIS can be traced to the 
employment of electronic accounting machines (EAM) that were commonly 
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utilized for accounting and payroll applications during and prior to 
World War II. However, some shipyards further extended the EAM capa- 
bility to the processes of monitoring job order schedules, personnel 
skills, and material inventories. When digital computers began to 
appear in naval shipyards in the early 1950's, these types of data 
were the ones most commonly transferred to the then revolutionary 
record-keeping system. The first shipyard computer applications became 
merely high-speed duplications of the electronic accounting machine 
system without any changes to the EAM routines. 

As each individual shipyard recognized the benefits to be gained from 
having its own computer in residence, and the funds became available, 
the shipyard would obtain a computer system. Since no direction or 
guidance was provided by the Bureau of Ships (BuShips), the forerunner 
of the Naval Sea Systems Command, each shipyard acquired the computer 
configuration of its choice, and used it for whatever applications it 
alone preferred. Thus, it was possible to find a relatively sophistica- 
ted financial accounting system at Puget Sound Naval Shipyard, for 
example, excellent production control at Mare Island, little more than 
payroll applications at Philadelphia, and a design orientation at Boston. 

Prior to 1960, no organized or standardized approach to information 
processing was to be found in the naval shipyard system. This situation 
could be partially explained by the different ship-type orientations of 
the various shipyards. However, regional differences of work force com- 
position and historical influences were also contributing factors. The 
reasons for the differences not withstanding, the varieties of operations 
encountered were enormous. Extreme variations of nomenclature also 
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prevailed. A process known by one name in one shipyard would be called 
something else in another, while the same name could refer to widely 
differing processes in others. This nomenclature problem was further 
complicated by considerable variances in the planning, processing, and 
reporting procedures encountered across the shipyard complex. 

A standardized shipyard data management system was initiated by 
SECNAVINST (Secretary of the Navy Instruction) P10462-7 of April, 1959. 
This instruction undertook to outline the goals and objectives for the 
Navy-wide use of automated data processing (ADP) equipment. The use of 
ADP in the development of budgets, plans, programs, schedules, and other 
management tools was directed by the Instruction. The use of complimen- 
tary and standardized automatic data processing equipment, as well as 
more centrally developed ADP systems throughout the Navy were also 
called for. 

As a result of SECNAVINST PI 0462-7, BuShips established a committee 
to investigate the possibilities of creating a shipyard management infor- 
mation system-like process in compliance with the Instruction. As a 
result of the efforts of this group, it was decided to develop a 
standardized management information system for all naval shipyards in 
early 1961. The system was to be called the Bureau of Ships Management 
Information System for United States Naval Shipyards . This became the 
forerunner of the current Shipyard Management Information System. 

Various pilot elements of a standard Shipyard Management Information 
System had been developed by 1962 at the Mare Island and Philadelphia 
Naval Shipyards. The first standardized configuration was designed by 
adopting the best available system oriented elements from the individual 
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shipyards and attempting to integrate them into the overall system. The 
Boston Naval Shipyard assumed the testing site function toward the end 
of the developmental cycle. Boston ^s goal was to integrate the com- 
ponents of the system that were developed by the other shipyards into a 
cohesive system and resolve all interface problems between system appli- 
cations. At the completion of this initial test, the system was instal- 
led in a total of six of ten shipyards who possessed alike computers. 
Shipyard managers then began to utilize the^ products of the Shipyard MIS 
Shortly after the system was installed, it became readily apparent 
that should each individual shipyard be allowed to generate its own pro- 
gram "improvements" or develop its own unique reports, problems could 
develop with the required systems products. Compatibility between 
installations would suffer and gradual disintegration of the standard- 
ized MIS system would result. In July, 1965, to combat this potential 
negative aspect, NAVSHIPS, as the Bureau of Ships was now called, estab- 
lished the Computer Applications Support Office (CASDO) and physically 
located it at the Boston Naval Shipyard. CASDO was able to make the 
necessary changes to the system that corrected problems not previously 
revealed by the Boston test. By the summer of 1966, the Shipyard MIS 
was operational in seven of ten shipyards. Not only did CASDO succeed 
in solving the large number of the problems involved in the initial 
design and provide for maintenance procedures of the large computerized 
system, it also was able to provide in-depth documentation of the system 
By the late 1960 ‘s, most of the shipyards had obtained standard com- 
puter configurations thus eliminating the initial problem of system 
implementation. The unique equipment set-up at some yards had led to 
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severe problems. In 1973, a program designed to revise and upgrade the 
standard system configuration was started since must of the initial 
equipment was becoming badly overloaded. Newer machines offered more 
computational speed, more memory, and other innovations such as multi- 
programming, real-time data storage and processing, and timesharing. 
NAVSHIP Instruction 5260.1 of January, 1973, directed the implementation 
in all naval shipyards of the standard Shipyard Management Information 
System as it is recognized today. 

The computer configuration that was chosen for the new standard 
system was the Honeywell 6060 which is designed primarily for business 
applications in the COBOL language, but is able to support other problem 
types and languages. This was considered to be a large-scale machine 
employing the most modern technology. The 6060 is constructed in inde- 
pendent module form which allows a user to design his particular con- 
figuration to fulfill his immediate needs, yet allow for future expansion. 
The 6060 is able to support time-sharing, multiprogramming, local and 
remote batch processing, and real-time processing with each process 
having access to the same data base. 

C. CONCEPTS 

The design of the Shipyard Management Information System is based on 
seven underlying assumptions which reflect the similarities and, to some 
extent, the differences between shipyard operations and information sys- 
tem design. The following concepts reflect a general philosophy of man- 
agement information systems with a specific orientation toward shipyard 
processing requirements: Given the large volume of data flow, an auto- 

mated system must be employed in order to accomplish the required 
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systematic control and presentation of shipyard information in a low- 
cost and timely manner; the basic automated system for this information 
should be standardized in order to satisfy similar requirements for 
logical solutions to similar problems throughout the shipyard system 
complex. 

The form and structure of this standard Shipyard MIS should reflect 
the management philosophies contained in the controlling Department of 
Defense and Navy policy documents, although each shipyard would be 
allowed some latitude in providing for local requirements; the ultimate 
users of the output reports, the shipyard managers, should agree upon 
the format and style of those reports; first line supervisors are to be 
held accountable for the quality and timeliness of the inputs to the 
Shipyard MIS: development of raw data, especially concerning frequency 

of preparation, updates, and refinements, should be totally under local 
control; and, similar reports should be grouped into families with 
major differences between reports within a family being the manner in 
which the information is sorted. ' 

D.' FORM AND STRUCTURE OF THE SHIPYARD MIS 

The organization of the Shipyard Management Information System 
closely follows the formal departmental organization of the overall 
shipyard itself. Since four departments are directly concerned with the 
actual productive work within a naval shipyard, the Shipyard MIS has been 
designed to respond to demands for information from each of the four 
departments through three interrelated functional areas knows as sub- 
systems. The Planning and Production Departments compose the Industrial 
Management Subsystem, the Financial Management Subsystem is related to 
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the Comptroller Department, and the Supply Department in the concern of 
the Material Management Subsystem. These three subsystems are further 
broken down to a total of eleven functional systems elements known as 
applications. There are five additional, relatively independent, appli 
cations which have been grouped together into an Administrative Subsys- 
tem because they support shipyard functions that are not primarily 
financial, material, nor industrial, but are necessary for complete 
shipyard operations (see figure 4 with a continuation on figure 5) [14] 
The subsystems and their component applications will be discussed in 
order as follows: 

Industrial Management Subsystem 

Workload Forecasting Application 
Production Control Application 
Production Scheduling Application 
Performance Measurement Application 
Design Application 
Financial Management Subsystem 
Cost Application 
Budget Application 
Payroll Application 

Accounts Payable Reconciliation Application 
Material Management Subsystem 

Industrial Material Application 
Shop Stores Application 
Administrative Subsystem 

Radiation Exposure Information Application 
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Figure 4 SHIPYARD DEPARTMENT RESPONSIBILITIES AS RELATED TO THE SHIPYARD MIS ORGANIZATION 
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Cost Collection, Materials, Labor 
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Payroll Application 
Accounts Payable Application 



Personnel Management Application 
Plant Accounting Application 
Public Works Application 
Depot Maintenance Application 

Each application is designed in the form of a logically independent 
module that is able to communicate data to, and receive data from, other 
modules through a series of common data bases with each module capable 
of producing its own set of reports. As a size perspective, the Finan- 
cial Management Subsvstem is the laraest of the subsystems since it is 
required to handle the majority of the routine financial work of the 
shipyard. The Industrial Management Subsystem is intermediate in size, 
while the Material Management Subsystem is the smallest. 

1 . Industrial Management Subsystem 

The Industrial Management Subsystem of the Shipyard Management 
Information System is concerned with maintaining uninterrupted flow of 
productive work within the shipyard. In order to accomplish this, it 
addresses the planning and scheduling of work, foreceasts of manpower 
and material requirements, identification and correction of out-of-control 
(jeopardy) situations, and evaluation of the results of the productive 
effort. In order to provide prospective to the structure of this sub- 
system, and a general picture of the types of information required by 
shipyard personnel to enable them to make wise decisions concerning ship- 
yard operations, a summary of the shipyard work cycle is presented, 
a. Industrial Operations 

Since the primary mission of naval shipyards is to perform 
work in the conversion, overhaul, repair, dry-docking, and to maintain 
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a construction capability for naval ships, it can be accurately sur- 
mised that each type of work will cause some variation in shipyard 
activities. Since an overhaul function is a common denominator for all 
shipyards, that is the orientation to be taken here. However, before 
an overhaul can begin, several prerequisite conditions must exist. 

These are: the ship must be totally dedicated to the uninterrupted 

accomplishment of the work (availability); the spectrum of the work 
must be decided, prioritized, and authorized; sufficient funds must be 
available; and sufficient material and skilled manpower must be com- 
mitted to the overhaul. 

Three major phases of an overhaul are of concern to the 
Industrial Management Subsystem of the Shipyard MIS: they are the 

advance planning phase, the short-range planning phase, and the actual 
overhaul accomplishment phase. The advance planning phase will vary in 
duration depending upon the type and extent of the overhaul to be accom- 
plished. Normally, this phase is a relatively continuous process extend- 
ing from two to eighteen months prior to the actual commencement of the 
overhaul. As decisions are made on repairs and alterations to be accom- 
plished, plans will progress from very rough and sketchy to a more 
refined and defined form. 

The short-range planning phase varies from six to eight 
months before the time of the ship's arrival in the shipyard until the 
time it is made available for shipyard work, which is not necessarily 
the same time. During this phase, preliminary estimations of the man- 
hours, personnel, materials and cost of the repairs and alterations are 
accomplished. This information is placed on job orders which direct 
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work to be performed by component key operations called KEYOPS. This 
phase also includes an inspection of the ship by representatives of the 
Planning and Production Departments to determine the accuracy of initial 
estimations and refine any design services and special materials that 
may be required. An arrival conference is held immediately upon the 
ship's arrival in the yard to review the scope, priority, and authori- 
zations of the job orders and to finalize the overhaul plans. 

The actual performance of the overhaul is the third phase.. 

The Production Department is held responsible for the successful comple- 
tion of the overhaul. A Ship Superintendent is assigned to each ship to 
serve as liaison between the ship and the yard and is responsible to the 
Repair Officer for the coordination and progress of all authorized work 
that is summarized by the individual job orders. As jobs are finished, 
the Ship Superintendent will witness the testing of the completed work 
and obtain certification signatures on the various job orders.from the 
cognizant shipboard department heads. The overall effectiveness of 
the completed repairs and alterations will be demonstrated by the 
conduction of appropriate at-sea or dockside trials prior to the departure 
conference to certify the overhaul completion or to identify any remain- 
ing items of work to be postponed, reassigned to ship's force, or 
eliminated. 

From the foregoing summary, it becomes obvious that an 
effective planning function is critical to the smooth operation of the 
overall productive work cycle. Planning provides the "bench mark" data 
required to establish control over the total overhaul. Data that is col- 
lected at the start of the cycle includes information on the planning 
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and scheduling of productive work primarily as forecasts of manpower 
and material requirements. Control over the accomplishment of the 
work results from detailed comparisons of planned versus actual expend- 
iture of time, labor, and material resources as well as an overall 
evaluation of the work once it is accomplished. To this end, the 
five applications of the Industrial Management Subsystem of the Ship- 
yard MIS are designed. 

b. Workload Forecasting Application 

This application provides three types of significant infor- 
mation to shipyard managers: a forceast of the overall shipyard work- 

load; an analysis of work actually issued to the ships; and an accounting 
of man-day expenditures performed against the issued work. Each of these 
elements is also compared against each other as well as to force avail- 
able information which provides a means of predicting work force 
requirements. A built-in simulation device allows shipyard managers to 
test the effects of manipulation of workload and schedules through incor- 
poration and processing of revised data transaction inputs. These 
adjusted and revised inout factors are processed through the MIS as 
though they were actual data inputs, the difference being that the out- 
put reports are flagged by the transaction codes as potential changes 
due to the manipulative effects upon manpower and scheduling. These 
reports are available to a particular shop or to the Production Depart- 
ment on a request basis. 

The major files of the Workload Forceasting Application are 
the Force History File, the Master Workload Transaction File, and the 
Manning Curve Master File. The Force History File stores transactions 
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relating to manpower availability on a daily, monthly, and quarterly 
basis; both productive and supportive personnel manpower availability 
records are maintained and refefenced by ship. The Master Workload 
Transaction File stores all data on the forecasting methods employed by 
each shop, work category, for each shipyard requirement; the work start 
and work completion dates as well as the number of man-days in each 
workload estimate are maintained. The Manning Curve Master Files stores 
all data that relates to manning curves employed by the various shops 
to forecast their individual workload requirements. 

Inputs to the Workload Forecasting Application include infor- 
mation on work force composition, job load forecasting and material 
expenditures. Forceast data are extended to include adjustments based 
on varying conditions of performance and shipyard loading trends, as 
well as actual versus predicted cost. The forecast is spread over a 
time domain through the use of manning curve diagrams provided by the 
Production Department. Load data, which identifies man-hours scheduled 
and issued for specific job orders, is an additional input as is the 
actual man-hours expended on a specific job. This series of inputs encom- 
passes work that is predicted, issued, and accomplished. 

Outputs of the Workload Forecasting Application are divided 
into three report families: workload forecasting reports, which inform 

shipyard managers of the anticipated shipyard workload by ship and shop; 
load reports, which present information on work that has been scheduled 
and issued to the shops; and force distribution reports that provide 
information indicating actual man-days expended and compare current 
manning information for forecast figures by ship, shop, and shift. 
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c. Production Control Application 



The Production Control Application of the Shipyard MIS pro- 
vides for current and valid information on the status of work within 
the shipyard. In general, this application enables shipyard managers 
to compare expenditures of manpower and material to allowances and to 
related schedules. Inputs to the application include scheduled shop 
manpower loading information, daily direct labor and overtime reports, 
labor estimates, authorized work listings, scheduled and actual dates 
for all customer job orders and associated key operations. 

The major files of the Production Control Application are 
the Performance Standards File, and the Performance Schedule File. The 
Performance Standards File, PROFILE, stores all data that is necessary 
to compute work center performance by type of measurement standard. The 
results are then in turn supplied as inputs to the predicted end-cost 
calculation, and are subsequently transferred to the Performance Measure- 
ment Application. The Performance Schedule File stores transactions on 
scheduled start and completion dates and other scheduling information. 

More than fifteen output reports grouped into five report 
families are generated by the Production Control Application, On- 
request status reports provide details on the status of all job orders 
by shop and become a convenient method of assessing what has been allowed 
versus what has been expended on each job in the shipyard. Direct labor 
analysis reports provide managers with weekly summary information on 
labor expenditures by ship and serve as a continually updated prediction 
on the final anticipated expenditures of direct labor for each ship in 
overhaul. Jeopardy reports identify potential problem areas in scheduled 
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work areas by indicating which areas appear to be endangering proper 
job completion, or are being overcharged. KEYOPS scheduled to start/ 
complete reports enable management to monitor key operations that are 
scheduled to start or complete within a particular time frame. Pro- 
duction control reports facilitate the monitoring of man-hours issued 
and man-hours expended versus authorizations. 

d. Production Scheduling Application 

This application of the Shipyard Management Information 
System is designed to assist personnel of the Planning and Production 
Departments in the planning and controlling of shipboard work schedules. 
Because of the normally nonrepetitive nature of shipyard work, especially 
as it applies to a specific ship, a formal scheduling procedure is 
required which permits efficient resource utilization and supports com- 
plete performance of all scheduled tasks. The products of this sched- 
uling system are used to assess changes that will be necessary in order 
to meet schedules, and in determining when schedules cannot be met. PERT 
(Program Evaluation and Review Technique - used for managing the duration 
of projects) and CPM (Critical Path Method - used to manage both duration 
and cost of projects) provide the basic formalized techniques to be used 
in providing schedules. The scheduling task is accomplished by employing 
the probabilistic PERT techniques and the deterministic CPM techniques in 
association with comprehensive formulas contained within the computer 
programs . 

Inputs to this application include descriptions of the sequence 
and extent of all KEYOPS to be accomplished during the overhaul, estima- 
ted and actual start dates, estimated completion dates, changes to job 
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orders, and event and activity data. The Production Scheduling Appli- 
cation is also able to accommodate manually developed schedules and 
provide for the rescheduling of linear, Gantt-type, schedules based on 
key events. One major file is employed in the application, the PERT/ 

CPM Master File. This file stores all scheduled start and completion 
dates calculated by the PERT/CPM formulas, storing them by KEYOP title 
and key event number. 

More than forty-five reports are produced by this applica- 
tion. They are broken down into six report families including error 
reports, activity reports, event reports, schedule date reports, auto- 
matic update reports and automatic rescheduling reports. Error reports 
are designed to assist the schedulers in the correction of input errors. 
Activity reports consist of differently sequenced listings of activities 
contained within the total project network. Event reports are concerned 
with PERT-type event information relative to a point in time. Schedule 
date reports provide shipyard managers with the latest changes in project 
dates. Automatic update reports provide automatic measures of progress 
for those activities in the overhaul project that may not have a visible 
progress, as in crew training. Automatic rescheduling reports indicate 
the results of automatically rescheduling KEYOPS. 
e. Performance Measurement Application 

The Performance Measurement Application measures the variances 
between planned work and the results of those plans. The application also 
processes actual scheduled time and man-hour performance data across the 
shipyard organization, measured against standards of productive work 
Cengineering, uniform, estimated, and nonstandard) in areas where such 
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standards may exist. Inputs encompass a wide variety of data including 
scheduled and actual shop workload, Design Division estimates, and 
scheduled and actual completion dates for job orders and key operations. 
Two files compose this application: the Standards Usage File, which 

stores all data and transactions concerned with allowances issued 
against each of the four types of standards; the Foreman Master and 
Design Data File which stores data on foremen and design codes, allow- 
ances, expenditures for the data period, and design drawing file numbers. 

The four families of Performance Measurement Application 
reports are schedule performance, allowance/expenditure performance, 
standards issue, and standards coverage. Schedule performance reports 
provide information on key operations completed, jobs ahead and behind 
schedule during the reporting period, as well as a percentage of schedule 
adherence. Allowance/expenditure performance reports provide further 
allowance versus expenditure comparisons clssified into exception, design, 
formen, and standards type reports. Standards issue reports compare 
man-day allowances to the four type of standards and provide a comparison 
of individual standards allowances with related total allowances. Stand- 
ards coverage reports present data on total man-hour allowances issued 
for each of the four standards types, 
f. Design Application 

The Design Application provides shipyard managers with infor- 
matton which reflects the status of the Design Division's efforts on Naval 
Sea System Command (NAVSEA) drawings, shipboard service alterations (SHIP- 
ALTS), alterations to ordnance equipment (ORDALTS), work items, special 
projects, and test memos within the shipyard. The application generates 
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current and historical workload data as a basis for determining future 
manpower requirements, with related allowances, expenditures, and 
schedules. Inputs to the application include data on man-hour estimates, 
and actual labor expenditures to locate and/or develop the required 
drawings, test memos, and special projects. 

Three files are utilized by this application: a Master 

Description File, a Historical Data Update File, and a Master Schedule 
File. The Master Description File stores data that describe all SHIP- 
ALTS and work items, including titles and numbers of the documents. The 
Master Schedule File is the main file of the Design Application, it 
stores all data and transactions concerned with drawing records including 
dates of issue and man-hours required to prepare the drawings. The His- 
torical Data Update File stores all transactions concerned with changes 
made to the Master Schedule File. The Historical Data File also con- 
tains histories of all changes to scheduled dates, as well as the date 
of actual issue of each drawing. 

Reports generated by the Design Application include control 
reports, work package reports, schedule reports, an evaluation report, 
error listings, and file dump reports. The principal management reports 
provided by the application are the drawing schedules. These reports 
list the status of all drawings associated with each SHIPALT and/or work 
item of a particular ship. The schedule reports also provide the status 
of all drawings required for any new construction or conversion projects 
and all test memos that may be associated with a particular ship. 

2. Financial Management Subsystem 

The Financial Management Subsystem of the Shipyard Management 
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Information System is concerned with the total flow of industrial money 
within the shipyard. This subsystem provides controls over basic system 
inputs, validates charges to job orders, provides for accounting controls 
over productive and overhead work types, and generates budgeting data 
for the entire industrial portion of the shipyard. This subsystem is 
the largest of all the subsystems of the Shipyard MIS, providing more 
data and generating more reports than any other subsystem. The four 
applications of the Financial Management Subsystem are all concerned 
with the Navy Industrial Fund. 

a. Navy Industrial Fund 

The Navy Industrial Fund (NIF) is a revolving fund established 
by the United States Congress to provide naval shipyards with necessary 
working capital. Under provisions of the NIF, a cash allocation is made 
to the shipyard at the time the fund is established. The fund is replen- 
ished by billing customers for work performed, materials supplied, and 
is surcharged for necessary administration and overhead expenses. The 
advantage of an NIF is that it provides shipyard managers with a fiscal 
environment which closely resembles a commercial shipyard activity. 
Although a naval shipyard is designed to operate on a break-even basis, 
the key NIF measurement device is the variations between predicted and 
actual costings which places the shipyard managers in a profit-and-loss 
situation. Fixed price customer orders become an effect of the NIF on 
the relationship between shipyards and their customers since these orders 
establish firm guidelines and incentives for management to obtain per- 
formance within limitations of the designated fundings which, theoretic- 
ally, encourages efficiency and economy. Accordingly, four application 
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areas have been established within the Shipyard MIS Financial Management 
Subsystem: the Cost Application, the Budget Application, the Payroll 

Application, and the Accounts Payable Reconciliation Application, 
b. Cost Application 

The Cost Application accomplishes four major tasks for ship- 
yard management. First, it provides the cost information needed to 
monitor ship availabilities; second, it provides the expense information 
needed for the overall financial management of the industrial shipyard; 
third, it collects the data required to generate the shipyard Financial 
and Operating (F & 0) Statements; and fourth, it provides the means by 
which requests for additional cost data from NAVSEA Headquarters, other 
Navy commands, and the Department of Defense can be answered. The Cost 
Application is the largest application within the Shipyard MIS and 
processes an enormous amount of detailed cost accounting transactions 
daily, primarily to shipyard ledger accounts. 

Along with accepting transactions utilized within its own 
interest area, the Cost Application provides a wide spectrum of informa- 
tion to other applications. It receives raw man-hour expenditure data 
and transfers validated man-hour expenditures to the Production Control 
Application's PROFILE; it receives dollar data on materials and provides 
them to the Industrial Material and Shop Store Applications of the Material 
Management Subsystem; and it receives planned and work-in-progress man- 
hour data and provides them to the Workload Forecasting and Performance 
Measurement Applications of the Industrial Management Subsystem, 

The major files of this application are the Cost Master File, 
Validation Control File, and Transaction Master File. The Cost Master 
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File stores a summary of all transactions that are related to the cost 
of labor and material for productive work in progress by job order and 
shop, and includes data on overhead expenses. The Validation Control 
File contains basic data on the Customer Order Acceptance Record (COAR), 
plus control numbers which indicate the desired level of validation for 
charges, these control numbers allow for labor and material charges to 
be validated to the control number, KEYOP, shop, and work center levels 
as dictated by NAVSEA, and as augmented by local policy. The Trans- 
action Master File stores transactions concerned with unallocated costs, 
as well as the multitude of other daily transactions that are concerned 
with the updating of shipyard ledger accounts; examples are charges to 
work in progress, summaries of one-time charges, force data for NAVSEA 
reports, and price variance data. 

The Cost Application of the Shipyard MIS generates one-hundred 
and ten reports distributed among three report families. The families 
are: customer order reports, unallocated cost reports, and expense 

reports. Customer order reports are the major funds controlling devices 
employed by the Planning Department. The status of dollar expenditure 
for each customer order is provided and enables an accurate prediction as 
to the ultimate overhaul labor costs by ship. This family also provides 
a report which can be used to detect potential cost overruns in time to 
permit corrective action. Unallocated cost reports provide shipyard 
management with costing information that has not been specifically 
assigned to a billing account. Expense reports provide comparisons of 
actual charges to productive and general expense centers versus budget. 
Comparisons are shown in dollar values as well as man-day amounts. This 
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family of reports provides the information needed to continuously monitor 
expenses and to detect trends, thereby providing a tool to help control 
cost and remain within budgetary constraints. 

c. Budget Application 

The Budget Application is the smallest application of the 
Shipyard MIS. This application is concerned with: the generation of 

data to budget all shipyard work loads and yard-wide overhaul expendi- 
tures; monitoring of the availability and adequancy of operating capital; 
and summarizing loans and capital transfers for the reporting period. 

The Budget Application employs the budget worksheets as the primary 
input transaction element. The Budget and Statistics Division of the 
Comptroller Department is the principle user of output information from 
his application. Seven reports are generated which summarize; labor 
outputs by department; labor transfers between shops; employee leave; 
budget estimates for overhead by work centers, departments, and common 
group cost centers; as well as providing budget estimates of total labor 
and materials. 

d. Payroll Application 

The primary purpose of the Payroll Application is to accom- 
plish timely and accurate payment of all naval shipyard employees and to 
generate all of the reports required by shipyard managers to control and 
audit pay and leave accounts. A secondary purpose is to enable compliance 
with the many Department of Defense and Navy directives concerned with 
naval shipyard payrolls. The application may also serve tenant and satel- 
lite activities in the management of employee leave, payroll savings and 
bond programs. In accomplishing these tasks, the Payroll Application 
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establishes a payroll record for each employee withich includes per- 
sonnel identification data, rate of pay, and payroll deduction data. 

A Daily Clock Card for each employee is processed as input, and records 
his hourly charges or absences. The data is converted to labor and leave 
dollars by the application which in turn stores the information for 
future use in developing the payroll. 

There are four files employed within this application: the 

Pay, Leave, Bond, and Financial Institution Master Files. The Pay Master 
File stores all historical earnings data of all graded and ungraded 
employees and is updated daily by the Daily Clock Card. This file also 
contains a complete pay account for each employee. The Leave Master 
File contains the employee leave accrual and usage records. The Bond 
Master File stores payroll savings data and deduction instructions for 
United States Savings Bonds. The Financial Institution Master File 
stores the addresses of institutions which employees have indicated are 
to receive their allotments and/or net pay. In addition to the use of 
payroll data for pay purposes, data on man-hours and dollars stored in 
the Payroll Master File are transferred to the Cost Application and then 
to the Production Department's PROFILE for Production Control, Workload 
Forecast, and Performance Measurement reports. 

More than eighty different reports are produced by the Pay- 
roll Application. Five report families are represented: control reports 

are used to preserve the integrity of the timekeeping and labor reporting 
functions; audit reports provide the means to review and trace all pay- 
roll data; payroll savings reports present data on the progress of U.S. 
Savings Bond sales and savings allotments of full-time employees; 
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service reports include the actual paychecks themselves plus annual 
withholding statements; and management information reports present 
statistical data on the payroll. 

e. Accounts Payable Reconcilation Application 

Shipyard funds management requires an entry in the accounts 
payable account whenever Navy Industrial Fund material is received, and 
an entry in the material-in-transit account whenever NIF material is paid 
for prior to its actual receipt. The purpose of the Accounts Payable 
Reconciliation Application of the Shipyard MIS, is to provide the 
information needed to control and continually reconcile these two accounts. 
Ideally, this reconciliation should be a routine operation, however, due 
to processing delays, changes in prices, and partial deliveries, unliquid- 
ated or unreconciled balances have a tendency to accumulate in both 
accounts. 

Both civilian commercial and Navy supply system transactions 
are controlled by this application using the Accounts Payable/Material- 
in-Transit Master File. When a receipt of material is processed, the 
transaction will establish a record in the accounts payable fields of the 
file and blanks in the material-in-transit fields. When a paid bill 
transaction is received, the transaction is entered into the file, the 
two sides are balanced, and the record liquidated. The file also con- 
tains detailed historical data on document numbers, federal stock number 
transactions, unit prices, partial deliveries, and delivery quantities. 
Fifteen reports are produced by the Accounts Payable Reconcilation 
Application, most of which are tools designed to aid in the liquidation 
of unreconciled balances in the two accounts. 



75 



3. Material Management Subsystem 



The Material Management Subsystem is designed to provide con- 
tinuous quantitative, financial, and status information on industrial 
materials. Industrial Materials are those materials, and services, 
purchased with shipyard operating capital provided through the Navy 
Industrial Fund. The Shipyard MIS Material Management Subsystem 
processes transactions for Direct Material Inventory (DMI), End Use, 
and Shop Stores. Outputs include reports of material commitments for 
outstanding orders, receipts and issues, inventories, catalogues, trans- 
action exceptions, and a wide range of material status reports used to 
monitor and control the entire cycle of shipyard operations, 
a. Types of Materials Managed 

The productive work of a naval shipyard requires a wide range 
of materials and services which must be defined, ordered, controlled, 
stored, issued, and for some items, disposed of through excess channels. 
These materials are of three general types: shop stores, direct material 
inventories, and services. Shop stores are materials that are used on a 
regular recurring basis by the shipyard shops, these items are generally 
ordered in quantity for a particular shop and are stored at the shop in 
anticipation of normal consumption patterns. By far the largest invest- 
ment in shipwork materials are direct material inventories; DMI items 
are ordered against a customer order and stored for a specific ship avail- 
ability. The Planning Department is responsible for deciding which items 
should be ordered and stored as DMI - although they are not assigned a 
specific job order until the requirements for KEYOPS and job orders are 
establ ished. 
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In addition to shop stores and direct material inventory 
information, the subsystem handles data and information for a variety of 
services. Types of services included are travel and transportation, 
transport of material, utilities, printing and reproduction, and other 
contractural services. The commitments for these services are treated 
like end use material and are identified by alphabetic codes to desig- 
nate the particular service of concern. Shop stores and direct material 
inventory items may be obtained by purchase from local or national sup- 
pliers, from main Navy inventories, or from the Defense Supply Agency if 
the item requested is a standard stock item within one of those systems. 
All materials and services are requisitioned through the shipyard Supply 
Department and entred into the Shipyard MIS Material Subsystem as material 
control records and commitments of funds. Two applications form the 
heart of the Material Management Subsystem: the Industrial Material 

Application and the Shop Stores Application, 
b. Industrial Material Application 

This application of the Shipyard MIS records and controls the 
procurement, receipt, issue, and where necessary, disposal of shipyard 
direct material. The Industrial Material Application provides a bridge 
of information between order recording and actual material usage which 
spans status and inventory operations and leads to material support by 
job order and key operation references. A major goal of the application 
is to provide shipyard managers with essential information that is 
required in order to determine the quality of material support for pro- 
duction. Other goals include identification and status of critical 
items, determination of causes of excessive direct material inventories. 
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determi nation of error sources, and the determination of the cost of 
residual materials. 

The Industrial Management Application concerns itself with 
four different transaction areas: orders for goods and services (commit- 

ments), DMI, financial, and pre-pricing transactions. Commitment trans- 
actions establish new and liquidate old commitments and establish the 
various associated delivery dates. DMI transactions add, change, and 
delete Direct Material Inventory data including orders, requisitions, 
procurements, shipments, receipts, and transactions on excess material. 
Financial transactions address old dodlar data and errors related to the 
DMI transactions. Pre-pricing transactions provide for material charges 
against job orders before the material is received and the final price 
determined. The Validation Master File of the Cost Application is also 
employed in this application to determine whether a commitment has been 
made to a valid job order number. 

Inputs to this application include commitment data in the 
form of job material lists, receipts and adjustment data, issues, mate- 
rial status, and file maintenance and control data. The application 
processes these inputs and provides five report families: exception 

reports, status reports, control reports and reference reports. Excep- 
tion reports are used to report status data on all material classified 
locally as both critical and in jeopardy. Status reports provide com- 
prehensive status information on all material items ordered, due, on 
hand, and issued. Control reports provide dollar data on DMI usage at 
shops and expense centers. Situation reports include items for which 
delivery is beyond the required delivery data. Reference reports 
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contain cumulative history of all material transactions processed and 
functions as an aid in researching material discrepancies, 
c. Shop Stores Application 

The productive work of naval shipyards requires a wide range 
of materials which must be defined, ordered, controlled, stored, issued, 
and sometimes disposed of. Shop Stores are the consumable materials 
which must be used regularly by shipyard shops and are managed by the 
Shop Stores Application. This application processes all inventory trans- 
actions, projects material replenishments, prepares various shop stores 
catalogues, and generates a series of reports and output cards that aid 
in controlling stockage levels. 

Three files are maintained by the Shop Stores Application: 
the Stock Item Record File, the Leger File, and the Description File. 

The Stock Item Record File stores transactions on opening and closing 
balances and records all receipts, issues, and expenditures against 
each shop stores item. The Ledger File maintains opening and closing 
dollar balances for each shop store, together with the accumulated 
values of receipts, issues, and adjustments. The Description File 
stores descriptive information on shop stores items that is used in the 
preparation of replenishment requisitions and material catalogues. In 
addition to maintaining these system files, the application automatically 
initiates replenishment actions whenever stock balances reach a pre- 
determined reorder level. 

Inputs to this application include material receipts for 
shop stores, material issues for shop stores, management established 
parameters on the type and quantity of output information, and data on 
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item description such as prices, quantities of issue, and sources of the 
material. Twenty reports are distributed among the replenishment, stock 
status, catalogue, work measurement, and control report families. Replen- 
ishment reports project usage rates into recommended reorder levels and 
dates. Stock status reports provide total values of shop stores includ- 
ing total value statistics. Catalogue reports assist in the preparation 
of on-hand and available item listings. Work measurement reports provide 
a summary of inventories as well as statistical measures of shop stores 
activity. Control reports provide information on special actions that 
may be required to locate stock, correct errors, and transfer materials. 

4. Administrative Subsystem 

In addition to the eleven applications previously discussed within 
the three major Shipyard Management Information System Subsystems, there 
are five other applications which serve all other shipyard functions from 
a common data base. These miscellaneous applications are not directly 
classifiable into any specific subsystem since they are basically inde- 
pendent functions, but have been grouped together into the Administrative 
Subsystem for ease of identification and reference. They are: the Radi- 

ation Exposure Information Application, the Personnel Management Appli- 
cation, the Plant Accounting Application, the Public Works Application, 
and the Depot Maintenance Application. 

a. Radiation Exposure Information Application 

The Radiation Exposure Information Application of the Ship- 
yard Management Information System, maintains records on the cumulative 
exposure of shipyard personnel to ionizing radiation associated with naval 
nuclear propulsion plants for those shipyards who maintain a nuclear 
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capability. Report families produced by this application include indi- 
vidual exposure reports, job order reports, and radiation exposure 
reports required by higher authorities. A number of the reports genera- 
ted by the application are required by the Bureau of Medicine and Surgery, 
Energy Research and Development Agency, and the Headquarters of the 
Naval Sea System Command. Nearly all of the remaining reports are used 
to ensure that individuals do not receive more ionizing radiation than 
prescribed by the Bureau of Medicine and Surgery. 

The Radiation Exposure Information Application employs two 
files: the Radiation Control Personnel Master File and the Job Order 

Master File. The Radiation Control Personnel Master File contains all 
data transactions needed to report on personnel radiation exposure, 
including daily, weekly, monthly, quarterly, yearly, and life accumula- 
tions of radiation exposure dosages. Dates are also maintained in this 
file for scheduling radiation exposure training and the periodic medical 
examinations required for continuing qualification of individuals as 
nuclear workers. Transactions on radiation dosages are obtained from 
the Radiation Monitor and the Daily Dosimeter Reading Card which 
records time in and out of the radiation area, job order number, and 
dosimeter reading for each exposure, including zero readings. The Job 
Order History Master File contains job order, shop number, work category, 
job order title, and original and revised estimates of exposure to ioni- 
zing radiation, per worker. 

b. Personnel Management Application 

The Personnel Management Application of the Shipyard MIS 
maintains the personnel records of all civilian employees of the shipyard. 
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As part of this effort, the application provides current status informa- 
tion on individual employees, maintains files of pending personnel actions, 
and reports historical and reference information on a number of diverse 
classes of shipyard personnel statistics including turnover, average 
grade, position titles, awards, minority employees, reductions in force, 
welder qualifications, marital status and tenure. In addition, the appli- 
cation provides data inputs to the standardized Navy Automated Civilian 
Manpower Information System maintained by the Office of Civilian Man- 
power Management (OCMM); it serves the Training Requirements and Infor- 
mation Management System, also OCMM run; and it provides equal opportunity 
information and statistical analysis. 

All shipyard personnel data are input to the Personnel 
Management Application by the Base Industrial Relations Office. A 
matching program is employed to edit the integrity of data that are 
common to both the Payroll and Personnel Management Applications. The 
application employs nine separate files; a Master Data File of personnel 
statistics, two History Files, a Position Title File, a Department Table 
of Organization File, an Awards File, a Minorities File, and a Welders 
Qualification Master File. More than fifty reports are generated by 
this application to describe personnel actions and activities. Reports 
listings are available on demand which can respond to almost any desired 
personnel statistical profile by selecting and listing data stored in 
the files. Major report areas are distribution of civilian personnel, 
average grade computations by department, equal opportunity summaries, 
and age profile reports. 
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c. Plant Accounting Application 

The Plant Accounting Application provides the controls over 
Federal Government property that are essential to comply with the 
statutory requirements of the Secretary of Defense, and to fulfill the 
objective of insuring that information is available for management and 
technical purposes both on a physical, and a monetary, inventory of 
equipment basis. Information concerning Property Class 3 (other than 
industrial plant equipment) which includes all Navy-owned property with 
an acquisition cost of two-hundred dollars or more, and Property Class 
4 (industrial plant equipment) with an acquisition cost of one- thousand 
dollars or more, is required. 

Six basic input functions are provided to the Plant Account- 
ing Application. They are: intial loading transactions which report 

the acquisition of material; identification number changes which update 
history files; changes to master files; monetary changes which reflect 
depreciation and cost factors; dispositions of outdated and surveyed 
equipment; and transfers of equipment to the custody of another shop 
within the shipyard or to an external activity. The Plant Property Clerk 
is responsible for the posting of the transactions which reflect the acti- 
vities concerning plant accounting. Twenty output reports are divided 
into two report families. Plant account transactions reports include 
summaries of maintenance activities, a summary of acquisitions, equipment 
rejects and dispositions by class. Plant account file items report 
equipment items by nomenclature and Navy identification standard. Quart- 
erly equipment master lists, plant equipment lists, as well as inventory 
summaries are also provided. 
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d. Public Works Application 

The Public Works Application supports current Public Works 
Department reporting requirements. The objective of this application 
is to support facilities requirements in addition to reporting public 
works performance and financial accountability in support of the ship- 
yard industrial effort. Five report families provide information on the 
transportation, controlled maintenance, family housing, maintenance cost 
analysis and base utilities areas. 

The transportation report family provides a means for 
accounting for transactions processed for public works usage including 
operation and maintenance of vehicles. The controlled maintenance family 
uses the Shipyard Management Information System Daily Timecard as an 
input and produces weekly status information reflecting progress made 
by individual shops on Public Works Department work orders; these reports 
provide for completed work summaries and final costings including man- 
hour expenditures. Maintenance cost analysis reports are prepared from 
data extracted from the Financial and Operations File and reflect fiscal 
year cost data related to real property maintenance functions. 

Family housing reports provide maintenance status and occu- 
pancy rate information on military family housing within the shipyard 
Public Works Department's purview. This data is also extracted from 
the Financial and Operations File and is concerned with categories such 
as flag, officer, and enlisted occupancy statistics as well as an over- 
all cumulative housing report. Utility reports are prepared on a monthly, 
quarterly, and yearly basis and are concerned with power plant operations 
for those shipyards with their own power generating facility. 
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e. Depot Maintenance Application 

The Depot Maintenance Application provides for the accumula- 
tion, recording, and reporting of comparable information on the operations 
and accompli hsments of depot maintenance activities related to weapons 
systems supported and items provided. Beyond this, the application 
enables shipyard management to measure productivity, develop performance 
and cost standards, and determine where management emphasis should be 
directed. The application provides the capability to periodically review 
depot maintenance accomplishments in relation to: planned programs, the 

use of facilities provided for the support of weapons systems, depot 
maintenance cost in comparisons with the alternative of replacement 
cost of a specific item, and comparative costs among depot maintenance 
activities or between depot activities and civilian contract sources for 
the same type of work. Also, the application provides a catalogue of 
maintenance capability, shows where duplication of industrial capacity 
exists, and indicates both actual and potential areas for interservice 
maintenance support. 

Five digit Customer Order Acceptance Record, and ten digit 
job order numbers, accounting data, availability types and expenditures 
are extracted from the Cost Master File. Other required information is 
entered directly to the application by card input. Inputs consist of 
required file maintenance items provided for any data element on the 
Depot Master File including values of exchanged material, standardized 
inventory processes, and all codes for work categories of all non-shipwork 
areas. 
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The Master File Extract and Depot Maintenance File summarizes 
labor hours, labor overhead amounts, direct reimbursement costs, and 
material totals. It thus creates an updated Depot Maintenance Master 
File and produces output card decks which are used as inputs to the 
next activity, and creates a listing of all of the extracted data. The 
Depot Maintenance Hold File creates depot maintenance data for customer 
orders that have not yet been extracted from the Cost Master File. The 
Depot Master File is edited quarterly to insure completeness and validity 
of data. 

The Depot Maintenance Application provides ten output reports 
divided into two output families. Periodicity of a specific report may 
vary from monthly to annually depending on the requirements of the 
external agency or shipyard department to which the report is sent. 
Reports are produced which provide for the functions of audit control 
and information for internal management and higher authority reporting 
requirements. These provide summary information relative to the opera- 
tions and accomplishments of depot maintenance activities. Additional 
reports concerning the measurement of productivity, performance and cost 
standards, utilization of facilities, and depot maintenance costs as 
opposed to potential replacement costs are also provided. Since many 
shipyards do not provide weapons maintenance facilities, this applica- 
tion is not implemented in all Shipyard Management Information System 
activities. 

E. CONTROLS OVER THE SHIPYARD MIS 

The Headquarters of the Naval Sea System Command retains the respon- 
sibility for establishing the overall policy for shipyard management and 
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and the Shipyard Management Information System. The NAVSEA office 
assigned the overall responsibility for the Shipyard MIS is NAVSEA 07, 
the Industrial and Facility Management Directorate. Control over changes 
and alterations for the Shipyard MIS is the responsibility of the Manage- 
ment Information System Executive Group (MISEG). This top-level 
advisory group is composed of three senior Shipyard Commanders who estab- 
lish policies concerned with the Shipyard MIS and review all proposed 
system changes. 

The responsibility for the centralized design and implementation of 
the Shipyard MIS is vested in the Computer Applications Support and 
Development Office (CASDO). CASDO is an office of NAVSEA 07 whose over- 
all direction is provided by the MIS Executive Group, and is located in 
Boston, Massachusetts. CASDO does not initiate changes but provides 
central guidance, control, and coordination as it encourages the users 
of the system to suggest improvements. CASDO responsibilities include: 
identification and definition of shipyard information and data systems 
requirements ; system development; processes of integration with other 
information systems; technical direction on the development of required 
computer programs, including continuing maintenance; providing assistance 
in the implementation of the standardized MIS where necessary, including 
training of personnel in its use; control of the standards and proce- 
dures pertaining to the design, development, and implementation of the 
MIS, and any other shipyard computer based management system, as neces- 
sary. 

CASDO consists of a relatively small group of people whose backgrounds 
are in shipyard operations and computer systems. CASDO is not a programming 
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office. Should programming for the Shipyard MIS be required, CASDO 
writes a rigid set of specifications for the work to be done and sends 
it to one of the shipyards. Each shipyard specializes in one particular 
portion of the MIS. After the new program is written, corrected, and 
checked for accuracy, it is incorporated into the standard MIS package 
and distributed to all of the shipyards. Each shipyard originally 
employed nine to twelve programmers for such maintenance activities. 

1 . System Improvements 

In general, the major thrust toward systems changes reside with 
the system's users as encouraged by CASDO. Shipyard personnel continu- 
ally review the effectiveness of the MIS as it meets their needs, identify 
problem areas which reflect trouble or lack of information on the part 
of the user, and, in turn, report the problems to CASDO who reviews and 
passes them on to MISE6 for resolution. MISEG further reviews the prob- 
lem to assess its applicability to all shipyards, to ensure the proposed 
resolution will be consistent with NAVSEA policy, and to determine the 
technical and economic feasibilities of a system-wide resolution. CASDO 
and shipyard resources are employed for analysis, programming, and 
validation, as described above, prior to the issuance of any coordinated 
solution proposed for inclusion in the standard computer library of 
operations. 

2. Changes to System Outputs 

Because of the dynamic nature of shipyard management and infor- 
mation required for its support, the Shipyard Management Information 
System design provides for changes to the outputs, some of which may be 
made almost immediately at the request of the user. Depending on the 
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type of change requested, a review for approval process is initiated as 
outlined below: 



Change 


Changer 


Accomplisted By 


Add new reports; drop 
old reports; correct 
reports 


User 


Letter to MISEG indi- 
cating what changes 
are desired and why 




CASDO 


Review of request; 
letter to MISEG 


Error or deficiency 
within system other 
than with reports 


MISEG 


Approval to CASDO for 
change; Advises CASDO 
giving particulars 




CASDO 


Initiates corrective 
action 


Suggested improvement 
(a "good" idea) 


User 


Proposal letter to 
CASDO outlining justi- 
fications and cost 
savings 




CASDO 


Analyze and forward 




MISEG 


Approval to CASDO for 
change 


Change report parameters 


User 


Local request to data 
processing office 


Change file data; correct 
errors 


User 


Local request to DP 
office; file update 


Change request sequence 


User 


Local request to DP 
office 


Change report frequency 


Computer 

Operator 


Introduces appropriate 
transaction code to 
computer 



F. FUTURE OF THE SHIPYARD MIS 

From its inception, the Shipyard MIS was envisioned to have three 
evolutionary stages: The first stage allowed individual shipyards a high 

degree of autonomy and resulted in diverse systems and equipment; the 
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second stage called for the evolution of these systems and equipment 
into an aggregate of compatible, multipurpose subsystems, designed so 
that a high degree of uniform system products would be available to each 
shipyard. This stage required centrally controlled development of major 
subsystems and applications. The third stage is one of refining the sub- 
systems, largely through improvements and standardization of the system's 
programs, plus an expansion of system coverage. The Shipyard MIS is 
fully involved in this stage. 

Part of the plans for the future call for expansion of the Shipyard 
MIS through the design of new applications and the improvement of exist- 
ing ones. One area that is being designed for addition to the existing 
system is a Quality Assurance (QA) program. The QA function is already 
a large data-handl ing burden for shipyard operating personnel. Another 
application area requiring complete implementation is tool control. Ship- 
yards have a large investment in hand tools. Since the full incorporation 
of nuclear work in some shipyards, the criticality of some tools has 
increased and it is now necessary to provide for a completely automated 
tool inventory and control system. An area of great importance that 
will improve an already existing application by furnishing status reports 
on material movement within the shipyard are reports that will help to 
alleviate a major shipyard frustration: trying to locate material known 

to have been received, but which is presently at Some point between the 
receiving dock in the Supply Department, and the ship requiring the mate- 
rial. Development of a material progress system using on-line communi- 
cation techniques should not only eliminate this frustration, but also 
save many productive man-hours needlessly expended in the search for 



90 



the material. 



As can be surmised, future Shipyard Management Information System 
objectives will involve a considerable expansion and reorientation of 
the existing Shipyard MIS. Much of this expansion will consist of 
adding new applications to, or improving on existing subsystems. Because 
some of the proposed new applications may not logically relate to any 
of the existing subsystems, it may be necessary to develop new subsystems 
to accommodate them. Careful coordination of the various shipyard data 
processing centers, CASDO, and the MIS Engineering Group is required in 
this effort. 
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III. THE SHIPYARD MANAGEMENT INFORMATION 



SYSTEM AT MARE ISLAND NAVAL SHIPYARD 



A. INTRODUCTION 

Mare Island Naval Shipyard is located in Vallejo, California, at 
the northeastern corner of San Pablo Bay at the mouth of the Napa 
River. Seaward access to Mare Island is obtained through San Francisco 
Bay. From an intial land purchase by the Navy of 965 acres in 1853, Mare 
Island has grown through land reclamation and grants to its present size 
of more than 2,600 acres of hard land and almost 1,900 acres of tide- 
lands [15]. 

Mare Island Naval Shipyard (MINSY) is one of eight members of the 
Naval Shipyard Complex performing a wide variety of functions in support 
of the United States Navy. The other member yards are located in Ports- 
mouth, New Hampshire; Philadelphia, Pennsylvania; Norfolk, Virginia; 
Charleston, South Carolina; Long Beach, California; Bremerton, Washing- 
ton; and Pearl Harbor, Hawaii. The official mission of MIMSY, and all 
the other naval shipyards as established by the Secretary of the Navy in 
SECNAVNOTE 5450 of 21 April 1956 is: 

To provide logistic support for assigned ships and service 
craft; to perform authorized work in connection with con- 
struction, conversion, overhaul, repair, alteration, dry- 
docking and outfitting of ships and craft, as assigned; to 
perform manufacturing, research, development, and test work, 
as assigned; and to provide services and material to other 
activities and units, as directed by competent authority. 

Although each naval shipyard is capable of performing a variety of 
services in the accomplishment of this mission, the Commander, Naval Sea 
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Systems Command, has designated special assignments for each of the 
shipyards. Mare Island Naval Shipyard's special mission involves the 
construction, conversion, and overhaul of all types of submarines and 
the overhaul of surface ships, including nuclear, except aircraft car- 
riers [16]. The ship construction mission has since been deleted for 
all naval shipyards; however, portions of this capability still remain 
at Mare Island. The reactivation of MINSY's submarine construction 
capability would require considerable retooling and the acquisition and 
training of specialized craftsmen to obtain the balance of skills that 
are different from the present needs during overhauls. In order to 
adequately reestablish a construction capability from the present per- 
sonnel standpoint has been estimated to require at least two years. 

B. ORGANIZATION 

1 . MINSY Overall Organization 

Figure 6 depicts the organization of Mare Island Naval Shipyard 
as it releates to the data processing function, and shows the overall 
relationship of the major offices and departments of the shipyard to each 
other [17]. Primary responsibility for the operation of the shipyard is 
vested in the Shipyard Commander (Code 100) who reports directly to 
NAVSEA 07 (Industrial and Facility Management Directorate) on matters 
pertaining to the operation of Mare Island Naval Shipyard. The nuclear 
management structure of the shipyard is included for purposes of contin- 
uity. Within each organizational block, the shipyard functional code is 
provided since shipyard offices are often referred to by code instead of 
title. 
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NOTE 1: Direct Assess to Shipyard 

Commander on Nuclear Matters 



2. Organization of the Data Processing Office 

Figure 7 depicts the organization of the Data Processing Office 
(Code no) as it is further subdivided into an Analysis and Programming 
and an Operations Division. The Analysis and Programming Division is 
responsible for directing and coordinating the performance on non-engine 
ering automatic data processing systems design and analysis studies for 
all organizational components. This division is further partitioned 
into speciality areas with specific programmers assigned to specific 
sections of the Shipyard Management Information System as their partic- 
ular area of expertise. These specialty areas are concerned with finan- 
cial and material applications, and special projects. Industrial and 
advanced programming applications, although part of the MINSY data 
processing effort, have a dual responsibility to the Computer Applica- 
tions Support and Development Office (CASDO) and NAVSEA 073 (Industrial 
Activity Management Systems Division) for maintenance of the Industrial 
Subsystem portion of the Shipyard MIS for the Naval Shipyard Complex. 

The Operations Division is responsible for the planning, sched- 
uling, and directing of the operation of the data processing computer 
and its peripheral equipment within the Data Processing Center. The 
division maintains liaison with all shipyard departments in order to 
develop a schedule for the accomplishment of data processing activities 
in accordance with established priorities. It also provides assistance 
to the Analysis and Programming Division in programming and debugging, 
when requested, and reports difficulties in using data and programs 
supplied to the departments and divisions concerned. The scheduling 
branch performs report scheduling and distribution functions. Actual 
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Figure 7 DATA PROCESSING OFFICE ORGANIZATION 
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equipment operations are accomplished by the operations branch on a 
continuous twenty-four-hours-a-day, seven-days-a-week shiftwork basis. 
Keypunch facilities and personnel are also under the control of the 
Operations Division. Figure 8 provides a breakdown of personnel man- 
ning within the Data Processing Office by position, paygrade (6. S.), 
number of personnel at that level, and annual salary range as of Octo- 
ber, 1979. 

C. DATA PROCESSING GOALS REALIZED 

The primary objective of Mare Island's data processing facility, as 
summarized by the head of the Operations Division of the Data Processing 
Office, is to: "... be responsive to customer requirements. This 

facility provides a service to the user, and exists so that he has 
available the best information upon which to base his decisions." Thus, 
the overall objective of the Shipyard Management Information System, as 
implemented at MINSY, is to provide accurate and timely information in 
an easily understandable form that is practical, useful, and meaningful 
to shipyard decision-making efforts. Additional goals of a less general- 
ized nature include; cost control, economy, forecasting, planning, flexi- 
bility, and provisions for expansion. 

The MIS aids cost control by bringing together in an integrated data 
base the costs of labor, material, and operations which achieve increased 
j operating efficiency through better work scheduling and more effective 

[ use of personnel, equipment and inventories. Shipyard MIS functions are 

\ 

also integrated to provide economy of operations in that similar opera- 
tions are combined; data processed in one functional area is transmitted 
within the system to other applications which require the same information 
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Figure 8 



DATA PROCESSING OFFICE MANNING 
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which, in turn, avoids duplication of effort and reduces clerical tasks. 
Formalized Shipyard Management Information Systems methods of predicting 
expected future performance based on actual past performance are avail- 
able to fulfill the forecasting objective. The uncertainty of the 
future is minimized using the planning functions of the MIS in that 
data can be obtained, translated, understood and communicated to improve 
the rationale of current decisions that are based on future predictions. 
The Shipyard MIS is flexible in that it readily accepts changes such as 
new data files, new procedures, and new output functions. The modular 
design of the MIS allows for system expansion and response to evolving 
managerial requests and provides for advances in system products and 
additional services for system users. 

The primary functional area of support is the monitoring of the entire 
work process from planning of the work package to the certification of 
completion by the cognizant shipyard department head. This involves 
balancing the status of the work effort in relationship to the predeter- 
mined plans and schedules. Situations that are outside the established 
criteria for acceptable performance, based primarily on time and/or cost 
factors, are then to be highlighted as jeopardy situations so that mana- 
gerial attention may be applied. Monitoring and control, although not 
generally considered to be synonomous terms, are used interchangeably 
at Mare Island; they refer to the implementation of plans and the use 
of feedback, as demonstrated by figure 9, so that shipyard objectives 
are optimally attained. The feedback loop is the central concept of 
control /monitoring, and timely, systematic appraisals of operations as 
provided by the Shipyard Management Information System and is the chief 
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Figure 9 
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means of providing useful feedback to enhance shipyard operations, 

D, SYSTEMS AND APPLICATIONS OF MINSY's SHIPYARD MIS 

The Shipyard Management Information System at Mare Island Naval 
Shipyard is composed of four subsystems with a total of fifteen appli- 
cations. It is an integrated system with many interfaces between appli- 
cations. A data element is introduced only once and may then be used by 
many applications. Figure 10 illustrates the four subsystems and how 
they are broken down into their component functional application areas. 
Although each application was discussed in depth in Chapter II and is 
completely specified by reference 14, a brief description of each appli- 
cation as employed at MINSY follows: 

The Cost Application is by far the largest single application of the 
Shipyard MIS. It accomplishes four major tasks for shipyard management. 
First, it provides the cost information needed to monitor orders received 
from customers for work to be accomplished; second, it provides the over- 
head information needed for overall financial management of the shipyard; 
third, it collects the data required to generate the shipyard's Financial 
and Operating Statements; and finally, it provides the means and resources 
to answer requests for additional cost data from the Department of Defense, 
the Naval Sea Systems Command, and other Navy commands. 

The Budget Application assists in the development of the information 
required for the generation of the shipyard overhead budget. The purpose 
of the Payroll Application is to accomplish the timely and accurate pay- 
ment of all shipyard civilian employees and to generate all of the related 
reports required by the shipyard and various governmental agencies. The 
Accounts Payable Reconciliation Application provides the information 
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Figure 10 SHIPYARD MIS SUBSYSTEMS AND APPLICATIONS 
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needed to control and continually reconcile the accounts payable account. 

The Workload Forecasting Application provides a forecast of the over- 
all shipyard workload for direct labor personnel, a comparison of man- 
days authorized to be expended by scheduled time-frame against available 
force, and an account of the expenditures of total man-days in comparison 
to the authorized and scheduled work. The Production Scheduling Applica- 
tion supports the establishment and control of work schedules. The Pro- 
duction Control Application provides information on the status of work 
in the shipyard. The Performance Measurement Application measures vari- 
ances between planned work and actual performance. The Design Applica- 
tion provides the tools for managing the engineering drawing and 
specification development effort of the shipyard. 

Shipyard material is divided into two types: direct material and 

shop stores. Direct material is that material that is ordered with a 
specific end use on customer funded work identified. Shop stores are 
the consumable and high usage/low unit value material items that are 
used regularly by shipyard shops. The Industrial Material and Shop 
Stores Applications support the management of two types of material. 

There is considerable interface between the two applications such that 
the using shops can be provided with a report identifying the status of 
all of the material required for a job regardless of its source. 

The Personnel Management Application, in conjunction with the 
standardized Navy Automated Civilian Manpower Information System (NACMIS), 
maintains personnel records of all civilian employees of the shipyard. 

The Radiation Exposure Information Application maintains records on the 
cumulated exposure of shipyard personnel to ionizing radiation associated 
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associated with naval nuclear propulsion plants. The Plant Accounting 
Application supports the inventory, acquisition, deletion and deprecia- 
tion of shipyard property and equipment. The Public Works Application 
provides information on operation and maintenance of transportation, 
utilities, family housing, buildings, and other facilities and equipment. 

E. DATA PROCESSING INPUTS 

Input to the data processing system comes from many sources. Data 
may physically enter the system on the standard eighty-column punch card, 
the design of which is controlled by various transaction codes (TCs). 
Information is also input directly into an application program by other 
application programs within the Shipyard Management Information System. 
Inputs to the Ship Work Control System, to be more thoroughly discussed 
later, are accomplished through terminal processing controlled by Trans- 
action Processing Applications Programs. 

1 . Transaction Codes and Designators 

A transaction is a set of input data which initiates a consistent 
operation or sequence of operations in a given computer program. Each 
transaction contains a code for identification. This transaction code is 
the means by which a program recognizes, classifies, and processes the 
data. The Shipyard MIS uses more than fifty- thousand different trans- 
action codes to allow for effective, economical processing of the millions 
of elements of data which must be stored in the Shipyard MIS computer 
files. The code itself is made up of three alpha-numeric characters pre- 
ceeding the transaction data. The first character identifies the appli- 
cation, the second and third characters identify the action required for 
the computer programs and prescribe the sequence in which the transaction 
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will be processed. 

Efficiency and economy of Shipyard MIS operations often neces- 
sitates construction of a computer program such that it offers various 
computational alternatives or options to the user, or allows him to enter 
data into the program itself. These computational alternatives are 
obtained by entering recognizable codes into the program; these codes 
are termed designators. In addition to providing management and opera- 
ting personnel a tool to control the system options, designators are 
also used to insert certain constants that may be desired as part of an 
internal computation. They are also used to insert common elements of 
data that may be used by programs such as "today's date". 

All inputs are in a fixed format as per input transaction code 
instructions found within each transaction code procedure. There have 
been attempts within the Operations Division of the Data Processing 
Office at MINSY to invoke free-formatting proc£dures, but they have met 
with resistance from local programmers and the CASDO office and thus are 
not likely to be implemented in the near future. Since there are thou- 
sands of input transactions within the family of structured inputs 
intended for the Shipyard MIS usage, it would be difficult to discuss 
all of them. Thus, the thirty-two transaction codes and designators which 
influence the operation of the Workload Forecasting Application of the 
Industrial Subsystem are summarized in figure 11. 

2. Keypunch Procedures 

Each transaction, if it is not presented to the data processing 
center on an eighty-column punched card, must be converted from the source 
document to the specific format required by the appropriate transaction 
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Figure 11 



INPUT SUMMARY 



General 

Heading 


Type Number 


Name 


Job Order 
Data 


TC 566 

TC 570 

TC 574 


Establish Job Order 
Amend Job Order 
KEYOP File Maintenance 


Time Card 
Data 


TC 055 


Daily Clock Card 


Performance 

Factors 


TC 160 


Shop Performance Factors 


Forecasts 


TC 273/4/7 
TC 260/1 
TC 262/3/6 

TC 264/5/7 
TC 270 
TC 272 


Manning Curve 

Ship/Project Manning Curve 

Shi o/Pro.iect External Load- 
ing 

Ship/Project Fixed Loading 
PWER Loading by Line Number 
PWER Workload Estimates 


Cancellations 


TC 268 


Ship/Project Cancellations 


Estimates 


TC 160 


Percent of Workload Esti- 
mate by Shop 


Shop/Code 

Rolls 


TC 271 

TC 0003 

TC . 269 

Design Card 0002 

Parameter 0001/4/5 
Card 


Shop Roll Adjustments 

Availability, Hull Index 
Number 

Absent 

Branch Code Statistics 

Parameter Months, Time Span 
Report Heading 


Reporting 

Options 


Designator PF20259 

Designator PF40260 
through 
40276 

Designator PF20254 


Work Category Selection 
Customer Order Selection 

Report Request 
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code that will enable the data to be inputed to the Shipyard MIS. MIMSY 

has established a library of 575 keypunch procedures that assist keypunch 

operations in the conversion of data from the source documents into the 

format/layout required for computer input. These instructions contain 

the following information: 

Document Code 
Originator Code 
Process Code 

Source Document Indicator with Instruction, if applicable 

Field Number Indicator 

Field Length 

Field Descriptor 

Card Column Instructions: 

X/B/0: X = must be keyed 

X/B = key if shown 
X/0 = fill with zeros 
Designator: 

Z/N/Z: A = alphabetic data 
N = numeric data 
Z = right justify and zero fill 
A/N = alphabetic and/or numeric data 
S/D = a skip or a duplicate field indicator 

Verification requirements are annotated by the letter "V" in the verifi- 
cation field. Each procedure also contains notes as to the disposition 
of missing or incorrect data fields found as a result of verification 
procedures. Instructions for the disposition of source documents are 
also provided. 

Source documents are identified as to the proper keypunching proce- 
dure required by the shop supervisor prior to data submission to the 
DP center. Hand-coded entries on punch cards are resubmitted by the 
keypunch operator. Source documents that are not restricted to being 
inputed for processing by cards are submitted by batch number to the 
CMC (Computer Machinery Company) key entry system which houses the 
formatted data on a disc until it is transferred to the appropriate 
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application file within the Shipyard MIS. Using this method, a journal 
file of raw data that is an image of keypunch transactions is kept as 
a backup and audit trail until such time as the transactions have been 
completely absorbed into the system (usually one week). 

F. DATA PROCESSING PROCEDURES 

There are more than four-hundred different reports that may be 
generated by the Data Processing Office at Mare Island Naval Shipyard. 

Each of these reports has its own unique processing requirements. It, 
therefore, is difficult to attempt a description as to how each of these 
reports is generated from raw data inputs, provide a listing of applica- 
tions programs utilized, describe each file routing and detail the sort- 
ing routines employed. The orientation of this section, then, is to 
generally describe data processing procedures of the Shipyard Management 
Information System at Mare Island Naval Shipyard using the Daily Force 
Distribution Report (PF-102A), which is generated from the Workload 
Forecasting Application of the Industrial Management Subsystem, as an 
example. 

1 . Application Programs 

Each application program resident within the Shipyard MIS is 
kept in its own binder within the data processing center of MINSY. Infor- 
mation contained for each of these programs include: a process chart of 

block diagrams illustrating the discs and/or tapes utilized; procedures 
for data extraction; a narrative description of any validation require- 
ments, the read file, sorting comparisons utilized, and tape-write 
procedures that may be needed; the sort sequence is given; a description 
of input descriptions that may be required and disposition instructions 
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for raw data; program disposition; periodicity and routing of output; 
description of constants, variables and control fields; a record of 
program changes; halts permitted; interrupt and restart procedures; 
associated data elements; and program listings as well as initializing 
test data are all provided. Two programs which provide the majority 
of the processing required to generate PF-102A are the Extract and Sort 
Program (PF-101) and the Edit and Update Force Data Program (PF-102). 

These two programs are further described below. 

a. Program PF-101 

The Extract and Sort Program, PF-101, is a Shipyard MIS 
application of the Honeywell provided Sort/Merge Program Family. This 
family of programs is able to accept a wide variety of data and task 
descriptions and dynamically adjust itself to the individual task required 
of it in order to provide for efficient processing. The Sort Function 
also features dynamic adjustment to the operating environment so as to 
maximize resource utilization especially during multiprogramming opera- 
tions. Varying input arrd output files are utilized depending on the 
specific sorting program to be employed by the requesting process. 

The Sort/Merge Family is engaged through a parametric descriptor 
program contained via the General Macro Assembly Program CGMAP). The 
parameters for sorting/merging are contained in macro control cards. 
Execution of the object program generated by these cards calls the Sort/ 
Merge (S/M) Program from the Software System Library File. The parameters 
are interpreted and the desired program function engaged at execution 
time. Normal operations require few descriptive parameters since stand- 
ardized functions and file descriptors are employed. Complex applications 
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including merging of variable v^/ith fixed record lengths or partitioned 
records or any combination thereof, can be accommodated by S/M. Flexi- 
bility is gained through the employment of optional parameters in the 
required macro control cards or by the inclusion of optional macro con- 
trol cards. 

b. Program PF-102 

This program edits the Daily Force and Schedule Load Files 
producing an output runoff (tape) which contains the two force reports 
in print format, reports PF-102A and PF-102B. These force distribution 
reports pertain mainly to man-hour expenditures on a day-by-day basis. 

The Daily Force (Input) File contains sorted force records used to 
process both reports. The Schedule Load File contains sorted load 
(authorized work force) and workload forecast records as inputs to the 
process. The Weekly Summary Input File contains the merged overhead force 
records from the start of the current processing week to the current data 
date, less one. At the start of the week, a sentinal tape replaces this 
tape since it has opened on the first day of the week. 

The Print Tape File contains the two output reports as a 
result of the processing, in print format. The Weekly Summary Output 
File contains the merged overhead force records from the start of the 
processing week to the current data date. After completion of the last 
force run of the week, this tpe becomes the input to Program PF-200, 

Force Distribution. Sequencing of records within the program is by 
report key and by major to minor sequencing by transaction codes. Man- 
hour inputs are converted to man-days and rounded off to whole days for 
reporting purposes. The program has no check points, and is scheduled 
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to halt only at the end of the job. If processing should stop for some 
reason, the program must be rerun in its entirety. The program requires 
four minutes of execution time and utilizes 57,675 positions of core 
space. 

2. PF-102A Generation 

Figure 12, with a continuation to figure 13, is the block diagram 
which illustrates the generation of the Daily Force Distribution Summary 
Report, PF-102A, and its sister report, the Daily Force Distribution 
Ship by Shop Report, PF-102B. Input is from three major areas: expendi- 

tures, load data, and forecast data. Expenditures information comes from 
time cards through the Financial Subsystem and into the Production Con- 
trol Application Program PC-100 and then into Program PF-101. Load data 
originates with job order briefs and also passes through the Financial 
Subsystem and PROFILE into PF-101, Forecast data originates with trans- 
action code input to Program PF-201 from which the data are then trans- 
ferred to PF-101. PF-101 extracts and sorts information in preparation 

for relaying it to Program PF-102 for editing and force updating purposes 
prior to producing the reports in print format. 

6. DATA PROCESSING OUTPUTS 

The primary thrust of the data processing facility at Mare Island 
Naval Shipyard is the production of reports that are responsive to 
directives from higher authority as well as serving the needs of the local 
user. There are more than four-hundred possible reports available from 
the MINSY Shipyard Management Information System, As described in Chapter 
II of this presentation, each functional application contains one, or 
more, data files which contributed information to one, or more, report 
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Figure 12 PF-102A GENERATION 
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Figure 13 PF -102A GENERATION (CONT'D) 
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families within that application. The Workload Forecasting Application 
constains three major files and three report families from which twenty 
different reports are generated. These reports are summarized in figure 
14, the Index of Reports. The purpose of this section is to describe one 
of those reports, the Daily Force Distribution Summary, PF-102A. 

1. PF-102A 

The purpose of the Daily Force Distribution Summary, PF-102A, is 
to assist Production Department Management in the monitoring of daily man- 
hour expenditures of the various shops and to make comparisons with the 
available force. The report contains man-days expended, loaded, and 
forecast for the previous day. This information is given for each ship 
and shop, and is summed for each availability type and for total shipwork. 
Total non-shipwork (manufacturing and other productive work, and military 
support) is also provided for each shop. Shop rolls with related absences, 
overhead, loans, and borrows are also presented along with resulting 
available force figures. 

Shop planners, shop heads, and group heads will review the report 
to see if expenditures for the previous day were at levels they expected. 

If expenditures are consistently below men-per-day forecast requirements, 
additional manpower assignments may be in order; comparison of available 
force to men-per-day forecasts may indicate a requirement to borrow 
additional manpower from other shops or shipyards, hire temporary assist- 
ance, or reschedule operations as necessary. This report provides a good 
short-term day-by-day check on the shop manpower situation. 

2. Sample PF-102A 

Figure 15 is a sample PF-102A report. This example shows items 
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Figure 14 



INDEX OF REPORTS 



REPORT 

NUMBER 


REPORT TITLE 


PF-102A 


Daily Force Distribution Report, Summary 


PF-102B 


Daily Force Distribution Report, Ship by Shift 


PF-200A 


Overhead Distribution Report by Cost Class-Weekly Summary 


PF-200B 


Overhead Distribution Report by Job Order-Weekly Summary 


PF-209A 


Scheduled Shop Loading Report, Shop/Work Center 


PF-212A 


Scheduled Shop Loading Report, Prod. Dept, by Ship 


PF-213A 


Scheduled Shop Loading Report, Ship by Shop 


PF-215A 


Workload Forcecast, Ship by Shop or Ship by Code 


PF-217A 


Workload Forecast/Schedule Load, Shop or Code 


PF-218A 


Workload Forecast/Schedule Load, Production Department 
or Design Division 


PF-220A 


Comments on Workload Transactions 


PF-220B 


Workload Changes Shop or Code 


PF-403A 


Planned Workload and Employment Report 


PF-405A 


Design Workload Forecast, 1-12 Months 


PF-419A 


Workload Forecast, Graph, Shop XX 


PF-419B 


Workload Forecast, Graph, Prod. Dept. 


PF-419C 


Workload Forecast, Graph, Shop XX 


PF-419D 


Workload Forecast, Graph, Prod. Dept, 


PF-903A 


Master Workload Transaction Report 
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which would be applicable to a ship undergoing a regular overhaul (ROH) 
availability only. Items applicable to the other types of availabili- 



ties would be included under separate category and then summarized in 
the TOTAL headings. Twenty-one items of special interest are highlighted 
for their importance and explained below: 



Item Heading 

1 SHIP/PROJECT 

2 ALL SHOPS 

3 

4 

5 TOT 

6 LOAD 

7 WLF 

8 TOT RO 

9 MFG OPW 

10 MIL SUPP 



Identification of Data 



The name of the ship and the hull type 
and number. In the case of non-shipwork 
projects, the code name of the project 
is used. 

Total man-days expended, loaded, and 
forecast for all shops. 

Man-days expended, loaded, and forecast 
for each shop. 

Man-days expended, loaded and forecast 
for each ship with ROH availability type. 

Total, Shipwork, Man-days. Figures do 
not include manufacturing and other 
productive work, or military support. 

Scheduled Load; Average men-per-day 
loaded (scheduled and issued), shipwork 
only, man-days are in terms of will cost. 

Forecast, Men-per-Day; Average men-per- 
day for shipwork only. 

Total Regular Overhaul; Total number of 
man-days expended (regular time), loaded, 
and forecast, plus that expended for 
overtime (OT) for ships within the avail- 
ability type. 

Manufactured and Other Productive Work; 
Repoted in man-days for work expended, 
TOT, loaded, LOAD, and forecast, WLF. 

Military Support in man-days for work 
expended, TOT, loaded, LOAD, and 
forecast, WLF. 
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11 


NON-MATCH ED 


Charges which do not meet assigned level 
of validation criteria and unreported 
straight time under eight hours. 


12 


TOT PROD 


Total Production Work; Including ship- 
work, manufacturing, and other pro- 
ductive work military support, overtime 
and non-matched. 


13 


SHOP ROLLS 


Total number of workers assigned to all 
shops, and to each shop. 


14 


ABSENT 


Employees on shop rolls who are not 
available for performance of productive 
work. 


15 


TOT MAI NT 


Total Maintenance; the sum of work 
expended for maintenance categories. 


16 


TOT OPER 


Operating Total; sum of the projections/ 
expenditures incurred for operating 
costs . 


17 


LOANS (SHYPD) 


Loans, Internal; the number of employees 
loaned to other shops within the shipyard 


18 


LOANS (EXT) 


Loans, External; the number of employees 
loaned to other shipyards, by shop. 


19 


BORROWS (SHYPD) 


Borrows, Internal; the number of employ- 
ees borrowed from another shop within 
the shipyard. 


20 


BORROWS (EXT) 


Borrows, External; the number of employ- 
ees borrowed from other shipyards. 


21 


AVAIL FORCE 
(PROD) 


Available Force; the number of employ- 
ees within a shop that are available 



for assignment to productive work. 

H, HONEYWELL 6060 SYSTEM 

In 1973, as part of the Shipyard Management Information System improve- 
ment program designed to upgrade data processing throughout the Naval 
Shipyard Complex, Mare Island acquired a multidimensional Honeywell 6060 
Information System. The 6060 was especially designed for large-scale 
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data handling based on the COBOL language. It relies on an index-sequen- 
tial method of file processing and incorporates a powerful database 
management system. Multiprogramming is supported in that up to sixty- 
three programs may be in concurrent execution. The versatility of the 
6060 operating system allows the following features: integration of 

local batch processing, remote batch, remote access, transaction proces- 
sing, interactive remote job entry, on-line document handling and time- 
sharing for maximum system utilization. Memory is organized into 1,024 
record blocks, each memory module contains 256 blocks (262,144 words) 
allowing for over 1.5 million words of main memory. One central processor 
is in residence with 384,000 words of memory [18]. Other system components 
and characteristics include: 

Basic Cycle Time = 500 nano-seconds 

Effective Cycle Rate = 16 nano-seconds per byte 

Six On-Line Model 181 Disc Units, one additional back-up unit avail- 
able 

Positioning Time = 10 milli-second minimum 

34 milli-second average 
60 milli-second maximum 
Transfer Rate = 416,000 characters per second 
Total Removeable Characters = 27.6 Million per disc 
One Character = 6 bits 
384 Characters per sector 
18 Sectors per Track 
6,912 Characters per Track 
20 Tracks per Cylinder 

Eight None-Track 1,600 bpi Tape Units, one additional back-up unit 
available 

Rewind Speed = 500 ips 

Transfer Rate = 42,000 bps 

Inter-Record Gap = 1,200 bits (3/4 inch) 

Tape Length = 2,400 feet 

Reader Speed = 1,050 cards per minute. 

Printer Speed = 1,200 lines per minute 

1 . 6060 Operating System 

Functions of the General Comprehensive Operating System (GCOS) of 
the Honeyv/ell 6060 Information System provide for logical programmer and 
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operator interfaces with the software system, provide for a common file 
protection and access control that is accessible from all processing 
modes, and maximize system availability through a comprehensive total 
on-line testing system. To perform these functions with the efficiency 
required for the MINSY multi -dimensional operations, GCOS serves as the 
overall manager for the operation of the integrated hardware/software 
system. As system manager, it is able to achieve maximum utilization 
of the total hardware system and supervise the multi processor/multi pro- 
arammino environment - MINSY's normal ooeratino mode. Significant GCOS 
features that are required to perform these functions are implemented 
as modules, programs, and subroutines, 
a. Functional Components 

Major functional components of the 6060 operating system 
include, with a brief description of each: a startup program package 

which provides a variety of system startup operations including the 
loading, initialization, and utility functions required for system startup, 
or restart following a system fault; system input modules allow for multi- 
input streams by accepting input from all system input devices into core 
only when needed; the system scheduler uses the job priorities and classes 
processed in the system input program to establish a dispensing queue to 
fit the requirements of the user's operation; the dispatcher keeps as 
many system components as possible in simultaneous use by selecting the 
highest priority program that can make immediate use of a processor and/or 
a peripheral subsystem; the peripheral allocator module schedules and 
allocates all peripheral devices used by the system; the memory alloca- 
tion function performed by the core allocator allocates memory space to 
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jobs entered into the system for processing. Operator-system interface 
messages are also available for exchange between system programs and the 
system console and are controlled by a GCOS module. 

b. Fault Processing 

The method by which faults are processed depends on whether 
the fault occurred within the system or within a slave program. If a 
system fault occurred, an error message is sent to the system console, 
and the content of the registers at the time of the fault are dumped. If 
a noncontrol processor found the fault, it requests an interrupt from the 
control processor. The control processor puts the noncontrol processor 
in a DIS (Display until Interrupt Signal) state and takes the dump. If 
the control processor detects the fault, it puts the noncontrol processors 
in a DIS state and takes the dump. If a program fault is encountered when 
operating in the slave mode, the fault causes interrogation of the user 
fault vectors. If the user specifies a fault processing subroutine, con- 
trol is transferred via this vector back to the slave activity. If no 
fault processing routine is specified in the user fault vector, an abort 
is set into the user program and control is transferred to the GCOS, for 
fault correction if possible. Faults that can be user processed are memory, 
divide-check, ovdrflow, command, illegal procedure, fault tag, and derail. 
Normally a second attempt to process a fault of the last four types will 
cause the program to fully abort. Those faults that cannot be processed 
by the user are lockup, parity, operation-not-complete, startup, timer 
runout, and shutdown. 

c. Input-Output Supervisor 

The Input-Output Supervisor CIOS) performs the acceptance. 
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initiation, and termination of all input/output (I/O) requests, I/O 
operations on the system are accomplished by using a memory I/O opera- 
tion instruction which, when followed by pertinent I/O parameters, give 
control to lOS to initiate activity on the peripheral subsystems or 
to the routine handler to perform the I/O. Capabilities of lOS include 
symbol ic-to-physical unit translations which cause symbolic file desig- 
nators employed by programmers to be converted to absolute physical 
assignments at execution time. Simulated tape processing on disc simu- 
lates the serial mode of data processing normally associated with magnetic 
tape to be performed on disc which provides a degree of divide indepen- 
dence to the svstem and allows reduction in orogram setuo time bv eli- 
minatina maanetic taoe use for some files. lOS responds to all interruots 
and takes aooroDriate action thus allowina the orogrammer to be relatively 
free of concern for the interrupt svstem of the comouter. lOS maintains 
queues of I/O commands but will not necessarily select queued commands 
for execution in the order in which they were submitted unless they are 
presented by a linked file. lOS maintains awareness of the status of 
each individual peripheral device in standby and ready modes, lOS 
verifies that the user has been granted permission for the permanent 
file access; lOS will also keep a record of the time spent by the proces- 
sor and each peripheral device for every program executed. These statis- 
tics are later recorded on the accounting file and printed on the 
execution report for later use in billing and system operation analysis. 

2. Data Base Manager 

Data base manager functions are provided by the File Management 
Supervisor (FMS) routines which provide for cataloging, control of storage 
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space, prevention of unauthorized access, protection against device 
failure, partial protection against incomplete or incorrect update, and 
protection against concurrent usage, 
a. Cataloging 

Cataloging is the method by which information concerning the 
file is kept and thus is the basis for all other services. Cataloging 
services allow files to be created and deleted and their descriptions to 
be grouped and modified. The FMS administers a structure of mass storage 
records to keep track of information about files and authorized users. A 
separate substructure is created for each user to record information about 
files and authorized users. A separate substructure is created for each 
user to record information about files catalogued under that user name. 

A System Master Catalogue (SMC) is employed as an index to these sub- 
structures. The SMC has an entry for each user authorized to reference 
catalogued files, to use the Time-Sharing System, or both. The records 
in each user substructure are organized to allow hierarchical grouping of 
files for the user. At the lowest level, there is a file description for 
each file in which is kept: information to allow mapping from file to 

source location; specifications by file creator; counts of jobs currently 
using the file; the information recorded by FMS about the file. At the 
highest level in the user substructure, there is a User Master Catalogue 
(,UMC) that indexes the substructure for the user. Where there are sub- 
ordinate catalogues, the UMC indexes each file description. When there 
are subordinate catalogues, the UMC indexes catalogues as well as file 
descriptions immediately subordinate to the UMC. 
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b. Control of Storage Space 

Although the File Management Supervisor does not specifically 
manage storage space, as it is managed by a space allocator in the GCOS 
section, FMS does accept and obey limits on space to be used for both 
I default and overriding specifications on devices to use, FMS obtains 

space for files to be created and releases space for files to be deleted 

i 

on fixed devices and on removable structured disc packs that are mounted 
at the time of the create or delete request. If enough space for creation 
is not available, the request is denied. If the request is for growth, 
growth is constrained to the named device, or, if not named, to the 
remaining device of the same type with space proportional to the current 
size of the file to be expanded. When the file is created or grown sub- 
ordinate to a catalogue on a removable structured disc pack, however, 
space is obtained only from that disc pack either for file create, or 
file growth. Without such a constraint, the ability to move a file from, 
off-line to on-line would be lost since mounting instructions are issued 
only for a single pack; the mounted pack cannot be dismounted since it 
contains the file description. The smallest allocation possible is one 
Honeywell defined "11 ink", which is 320 words, 1,280 9-bit bytes, or 
1,260 six-bit characters. Other allocation units are integer multiples 
of llinks of 1, 2, 4, 6, 12, 24, 36, 48, or 60. 

c. Protection Against Unauthorized Access 

1 

I Unauthorized usage of a catalogued file is prevented by means 

[ of passwords, permissions, and security locks. A password must be speci- 
fied for each user at the time a System Master Catalogue entry is prepared. 
Passwords can optionally be specified for catalogues and files. User 
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passwords, to permit reference of catalogue files, or to use the Time- 
Sharing System, contain one to twelve combinations of alpha-numeric 
characters, dashes, or periods. These are requested, in the Time- 
Sharing System, whenever a user requests admittance to the system pre- 
senting his individual name first. A strikeover mask is provided to 
prevent the password from being visible. Timed passwords are also 
employed for files or catalogues. 

When a file or catalogue is created or modified, the creator 
or modifier can specify what actions are permitted on the file, catalogue, 
or subordinate files or catalogues by what users. Both general and speci- 
fic permissions can be specified for a catalogue to apply to subordinate 
files or catalogues. Permissions can be specified by anyone, in general, 
or for specifically named users. When there are several levels of sub- 
ordination, the permissions at each level are accumulated. Permitted 
actions include Read, Write, Append, Execute, Modify, and Purge. If a 
request is received that requires a permission, the permission field is 
searched for general permissions first, then specific permissions, and 
then exclusions. Only the creator of a file is considered to have 
exclusive permission for that file's use. 

A file can be security locked to limit allocation of the file. 
Security locking of a catalogue limits allocation of any files subordinate 
to the catalogue. Allocation is denied to a security locked file if the 
request for allocation is from anyone but a user with LOCK permission, or 
the creator of the file. If a catalogue is security locked, any file 
subordinate to the catalogue cannot be allocated except to users who 
have LOCK permission for, or are the creators of, the file. Security 



125 



locking is performed by a catalogue operation similar to file creation or 
file modification. It can only be performed by a user who is the creator 
or has LOCK permission for the file or catalogue being locked. Similarly, 
removal of a security lock is performed by a catalogue operation that 
can only be performed by a user who is the creator or has LOCK permission 
for the file or catalogue being unlocked, 

d. Protection Against Device Failure 

Six facilities provide differing degrees of protection against 
common forms of device failure. Either files or catalogues, or both, can 
be protected: Verifying file writes may prevent data from being written 

to device space from which it cannot be subsequently read-, duplicating a 
file permits immediate receovery if one or more pages of a file on a 
device are unreadable, but the recovery time is not as quick as it is from 
verification; journaling file changes permits recovery if one or more 
pages of a file on a device are unreadable, recovery time is still not 
as quick as from duplication; saving a file permits recovery of the entire 
file, unlike duplication or journaling, the entire file must be restored, 
since restoration provides the version of the file at the time of the 
save, the file is generally out-of-date at the time of the recovery. 
Duplicating catalogues permits immediate recovery if a catalogue is 
unreadable, duplication of catalogues limits the number of files that 
require restoring to those contained on the failed device; saving of 
catalogues permits recovery of an unreadable catalogue, but recovery 
time is not as quick as it is from duplication, restoring from a catalogue 
save requires all catalogues and all files referenced from the catalogues 
be restored, restoring generally provides out-of-date versions of the 
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catalogues as well as the files. 

e. Protection Against Improper Update 

The File Management Supervisor cannot protect against many 
possible causes of a file being improperly updated since this would 
require not only FMS knowledge of the file format, but also knowledge of 
the file application itself. However, there are two causes of improper 
file update that FMS can provide protection against. First, when a job 
that is updating a file terminates abruptly, either because of job or 

t 

system failure, the file is left in a partially updated condition. FMS 
is able to cancel these partial updates.. Second, for new application 
programs that have been inadequately tested, FMS provides a way for 
testing programs against the production file without any danger of damage 
to the file. 

f. Protection Against Concurrent Usage 

One of the four available access options must be selected for 
controlling concurrent allocations to a file. The default option is the 
NORMAL operation which allows either multiple readers or a single writer. 
With this option, no interference of one job with another concurrently 
allocated can occur since only concurrent readers are allowed. Two 
other options, CONCURRENT, and MONITOR, allow both multiple readers and 
multiple writers to be allocated at the same time. With MONITOR, reads 
and writes to the file are controlled so that any that might interfere 
with the operation of another job are either prevented or delayed until 
the chance of interference is past. With CONCURRENT, however, no such 
control over reads and writes is exercised by the File Management System. 
The chance of interference of one job with another must be tolerated, 
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controlled by other means such as programming within each job or in a 
common file content manager, or at least controlled enough to decrease 
the chance or types of interference to a tolerable extent. One final 
option, READ WHILE WRITE, allows multiple readers and a single writer. 

The writer may interfere with the operation of the readers, but since 
only a single writer is allowed, interference between writers which might 
damage the file content cannot occur, and, of course, readers cannot 
interfere at any time with the operation of the writer. 

I. INCORPORATING ADDITIONS TO MINSY's MIS 

Any management information system that remains static and merely 
provides information to users that support existing methods of operation 
is not being used to its full potential. Managers of a system such as 
the Shipyard Management Information System at Mare Island Naval Shipyard 
must seek out user problems to determine whether or not the development 
of new managerial systems together with supporting information system 
data and reports is needed and can be cost-effective. Two examples 
follow which demonstrate how this has been done at MINSY. A summary of 
procedures utilized at Mare Island for local system improvements is also 
included. 

1. WOOD 

One of the perststent problems which has prevented effective 
shipyard planning and production control has been the failure to integrate 
all planning and estimating, design scheduling, and material ordering 
I functions of an availability in one production-oriented work package. 

WOJO, or the Work Oriented Job Order System, is an integrated planning 
methodology for developing, managing, and controlling industrially 
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oriented work packages for shipyard repairs and alterations during 
overhauls, conversions, and new construction [19], Under WOJO, work is 
planned and packaged in the manner in which it is to be accomplished by 
the various shops. This is actually done on a system or area basis such 
that a single Job Order issued to a shop for accomplishment may be 
composed of repair items, SHIPALTS, ORDALTS, and special project tasks 
all considered to be one job. 

WOJO requires that shipyard planning and scheduling activities 
for an availability be coordinated and integrated during the work scoping 
period. As defined by WOJO, work scoping requires all availability plan- 
ning inputs (design plans, planning and estimating, material ordering) 
to be specified, scheduled, and monitored as a whole - not as individual 
functional items. Accordingly, WOJO requires active participation from 
Design, Planning and Estimating, Scheduling, and Supply Department 
personnel, as well as representatives from other specialized shipyard 
organizational elements such as Combat Systems and Nuclear Power on an 
ad-hoc basis. The WOJO system is employed for those ships where much 
of the work on a system, or in a single location on board the ship, 
involves several closely related customer work requests that can best be 
accomplished as a single integrated effort by the work force. 

Twelve MIS transaction codes are required to enter WOJO inputs to 
the Shipyard MIS. These are input from three source documents: the 

Industrial /Financial Control Transmittal Sheet is the primary document, 
the Work Estimate Sheet and the Job Order Document are secondary inputs. 
Data entries must be complete and accurate in order to ensure that 
reliable data are recorded in the pertinent MIS files and are subsequently 
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reflected in the MIS output reports. The Industrial/Financial Control 
Transmittal Sheets are prepared by the lead planner who enters approved 
KEYOPS, man-hour cost estimates, scheduled dates, material cost estimates, 
and percentage prorations/translations as they are applicable to the 
various shops scheduled to perform the integrated effort. The Work 
Oriented Job Order System outputs are reflected in the Shipyard Manage- 
ment Information System Financial Subsystem. Nine reports are affected 
by WOJO transactions. These reports include items concerning proration/ 
translation percentages for charge-back procedures, man-hour allowances, 
a record of all such transactions, distribution percentage changes, and 
cost control . 

2. Ship Work Control System 

The Ship Work Control System (SWCS) is a computer-based system 
for maintaining listings of all outstanding and completed non-nuclear 
deficiencies, test documents, work authorized by the work permit system 
and other miscellaneous documents or certifications for each ship under- 
going overhaul or repair at Mare Island Naval Shipyard [20]. The SWCS 
upgrades the former Non-Nuclear Composite system, see reference 21, to an 
on-line system of direct computer entry and retrieval. This on-line system 
utilizes remote terminals to gain entry to the data base where information 
is stored. The access for retrieval of information is through a set of 
standardized codings available in detail in reference 20. 

The Ship Work Control System is managed by the Ship Work Control 
Center (Code 356) to provide, on demand, convenient locally generated 
management reports to assess the status of remaining work on non-nuclear 
shipboard systems. SWCS is a production-oriented system which keeps 
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track of the numbers of various types of source documents outstanding on 
a given ship. These source documents are each a source of some kind of 
shipyard action on the system involved. Each source document is assigned 
to a responsible code, to the shop supervisor level, for action. It is 
additionally identified by a unique report number. Key Event, compartment, 
deck, and location. SWCS contains a strong inherent managerial account- 
ability and control device in its requirement for Shop Supervisors to 
verify completion of the action called for by a given source document, 
and to sign the Code 356 copy of that document before the document can be 
cleared from the computerized system reports. This requirement, self- 
imposed by MINSY, serves to increase supervisory involvement, knowledge, 
and accountability for work status determination and lends considerable 
credibility to SWCS reports. 

a. SWCS Terminal Operations 

To provide the on-line capability, remote terminals, which 
are directly connected to the computer via telephone line, are spotted 
at various locations throughout the shipyard, see figure 16. These 
terminals contain a cathode ray tube for message display, a keyboard for 
data input and data base inquiry, and an eighty character wide printer 
capable of printing data which is sent to the terminal. These terminals 
allow for instant inquiry of the status of items on the data base. To 
provide for large volume reports, the Ship Work Control Center is equipped 
with a 132 character, 300 lines per minute printer, and a XEROX 7000 Com- 
puter Forms Feeder which provides for the printing of large volume 132 
character-wide reports and their subsequent reductions to 8 x 10 1/2 inch 
size paper. 
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Figure 16 



SWCS TERMINAL LOCATIONS 



Code 

Assignment 


Bldg/ 

Floor 


Termi nal 
Number 


Function/Location 


100 


521/1 


23 


Code 100 Conference Room 
1069 


113 


229/2 


1, 25, 27 


Data Processing Office 


133.11 


45/2 


16 


Non-Nuclear Inspection 
Division Records Center 


191.2 


55/2 


15 


Combat System Test Divi- 
sion 


280.48/365 


742/2 


19 


Ocean Engineering Test 
Center 


290.1 


69/2 


14 


HP&A Test Operation Branch 


330 


108/2 


6 


Drydock #1 Ship Supt. 
Office 


330/365 


Barge 

YRR63 


7 


Ship Superintendent Office 


330/365 


69/1 


8 


Berth 9 Ship Supt. Office 


330 


163/2 


9 


Berth 7/8 Ship Supt. Office 


330/365 


Barge 

YC-1449 


10 


Ship Superintendent Office 


365 


163/1 


11 


Berth 7/8 SWCC Satellite 
Office 


330/365 


664A 


12 


Berths 17/18/19 Ship Supt./ 
SWCC Satellite Office 


330 


69/2 


18 


Repair Officer Conf. Room 


330/365 


BAB 


22 


Drydock #3 Ship Supt. /SWCC 
Satellite Office 


365.1 


69/2 


2, 3, 4, 5 
& 26 


Ship Work Control Branch 
Main Record Center 


920/956 


46 


20 


Code 956 Office Area 


930/938 


128 


21 


Code 930.44 Shop Planning 
Office (938 Planners) 


938TCC 


69/1 


17 


938 Shoo Test Control 
Center 


950 


866 


.1 I 


Code 950.4 Planning Office 
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b. DATANET 355 



The DATANET 355 Front-End Network Processor (FNP) is a Honey- 
well provided high performance, stored-program FNP designed to match the 
large-volume communication needs of the 6060 multidimensional information 
system in general and the requirements of the Mare Island Naval Shipyard 
Ship Work Control System in particular. It features total integrated 
circuit logic construction and a memory size of sixteen or thirty-two 
thousand words on a memory cycle of one micro-second. DATANET can accom- 
modate data of variable word lengths of six, nine, eighteen, or thirty- 
six bits. All data words are individually addressable to allow highly 
efficient processing of tabular data. Ninety-eight instructions in an 
eighteen bit format are provided with one single-address instruction per 
word. Three index registers and multilevel indirect addressing, with 
indexing at all levels, give an addressable storage to thirty-two 
thousand words. 

The system organization of the DATANET 355 FNP follows the 
pattern of the 6060. It is a storage-oriented computer with its ov/n 
independent memory, processor, and input/output modules, see figure 17. 
These three basic modules are independently timed and operate asynchro- 
nously with each other. The processor and the I/O Controller, the active 
units, process data at their own rates and erquest cycles from storage 
modules, passive units, as the need arises. Only when the processor 
executes certain input/output instructions must the processor and the 
Input/Output Controller communicate with each other. 

Input/Output is designed to facilitate efficient real-time 
concurrent servicing of multiple terminals and peripheral devices. Up 
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Figure 17 DATANET 355 FRONT-END PROCESSOR 
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TO READER MEDIUM-SPEED 

OR PRINTER.! COMMON PERIPHERAL 

^ ADAPTER 



to sixteen adapters can be provided to accommodate a total data transfer 
rate of up to 500,000 words per second (with six to thirty-six bits per 
word). Sixteen levels of priority interrupt, with sixteen sublevels per 
level and corresponding interrupt masks, are provided. As a module of 
the 6060 system, DATANET is capable of simultaneously handling up to two- 
hundred teleprinter, or thirty-two remote batch users, or thirty-two CRT 
subsystems or an appropriate mix of the three classes. 

3. MINSY MIS Improvements 

The Director of Management Engineering (Code 140) at Mare Island 
Naval Shipyard serves as the focal point for Shipyard MIS matters includ- 
ing performance of special studies and projects in the fields of manage- 
ment information systems and related automatic data processing system 
requirements [17]. Code 140 coordinates requests for improvements to 
the Shipyard MIS, as they may related to the total shipyard complex, with 
the Data Processing Office and forwards the required information to CASDO 
and NAVSEA in accordance with NAVSEA directives. The Director of Manage- 
ment Engineering also serves as shipyard liaison with CASDO and NAVSEA 
073 as required to accomplish approved Shipyard MIS requirements [2]. 

On the local, MINSY, level, Code 140; assists local depart- 
ment heads in determining suitable methods for satisfying departmental 
informational requirements; audits the installed MIS as necessary to 
assure that it is serving its designed purpose and is operating effectively; 
annually reviews distribution and use of all ADp reports to ensure minimal 
distribution consistent with local departmental information requirements; 
reviews proposed local ADP reports, additions or modifications to the 
Shipyard MIS for necessity and to determine the optimum means of satisfying 
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requi rements involved in order to obtciin maximum cost-effectiveness for 
both the affected department and the Data Processing Office., 

When requesting local programmer or data processing services 
requiring: the development of a new data system, the modification of an 

existing system, other than correction of program deficiencies j or the 
generation of new or modified reports from the existing system, the 
cognizant department head is to provide the Director of flanagement 
Engineering a cost/benefit analysis, A feasibility study will be 
prepared using Code 140 and the requesting department's personnel, 
recognizing that the Shipyard Management Information System's develop- 
ment, implementation, and monitoring are under technical and coordina- 
tion control of the Director of Management Engineering, 

Modification requests must state specifically what the proposed 
revision is expected to accomplish, along with the benefits, including 
dollar cost savings, and relate this to an established functional or 
organizational responsibility. Cost savings can be of three types: 
direct savings resulting from the computer performing tasks that are 
currently done manually, or a new reauirement that is cheaper to perform 
under ADP as opposed to manually, this type of saving is the best justi- 
fication providing there is a genuine need for the generated output; 
indirect savings result from productivity improvement as a result of the 
use of additional or more timely data; and intangible benefits which 
improve morale or work quality that cannot usually be quantified. The 
requests must also include anticipated problems and recommendations for 
the resolution of those problems. Lastly, organizational charts delineat- 
ing the decision points to be satisfied by the proposed modification in 
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relationship to the cost/benefits of the present methods must also be 
included. It is with this whole spectrum of requirements (paperwork) 
that only those modification proposals that will genuinely benefit the 
Shipyard MIS will be initiated. 

J. PHYSICAL SECURITY 

Since Security of the internal computer data base was adequately dis- 
cussed under the Data Base Manager section of this chapter, this section 
will address physical security precautions implemented for protection of 
the data base and the data processing equipment in the Data Processing 
Center at Mare Island Naval Shipyard. The center is manned twenty-four- 
hours-a-day, seven-days-a-week every week of the year with the exception 
of Thanksgiving and Christmas Days. When the center is not manned, motion 
and temperature alarms are activated to monitor unauthorized activity. 

Each member of the data processing staff is known by sight by every other 
member of the staff. Report disssemination from the DP Center is care- 
fully controlled in that only authorized guard-mail or messenger personnel 
from the affected departments are allowed to remove outputs from the 
center. 

Terminal security is provided by the previously mentioned password 
system, which is changed periodically, and the security "kernal" methods 
alluded to that are resident within the operating system. Security of 
each terminal is also provided by each location within which a terminal 
resides. A time lockout system for terminals has been suggested but not 
yet implemented. The highest Department of Defense level of information 
contained within the system is "Confidential". Annual, and as requested, 
security inspections of the system are also provided by the Security 
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Department; Mare Island Naval Shipyard itself also provides overall 
security in the form of a contingent of United States Marine Corps per- 
sonnel stationed at MINSY and a Mare Island Police Force. Fire protection 
is provided by smoke and heat alarms. A "v/et" fire suppressant system 
is installed with plans to implement a halogen-based system in the future. 
There is only one entrance to the computer and data storage room, which 
is secured by a cypher lock system. The data storage room is separated 
from the computer room by a heavy steel door. Finally, the building itself 
is an innocuous appearing structure with no signs labeling it as a data 
processing site. There are no windows in the computer equipment or storage 
rooms which are further separated from the outside world by two fire 
doors in addition to the cypher door access. 
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IV. DISTRIBUTED DATA PROCESSING AT 



MARE ISLAND NAVAL SHIPYARD 



A. INTRODUCTION 

It is recognized that distributed data processing as defined in 
chapter I does not currently exist at Mare Island Naval Shipyard. What 
does exist is a front-end network processor, the DATANET 355. The use of 
a front-end communications processor associated with a large computer is 
an accepted practice in modern data processing. Few large-scale systems 
do not rely on data communications to serve at least some of their uses. 
While some large corporations have instituted a policy of using large 
minicomputers and medium-scale computers rather than large computers to 
meet all corporate distributed data processing needs, most corporations 
have preferred to build outward from a well-established central computing 
facility. This approach to DDP may not be bold, but it is sensible. By 
retaining the large systems, users protect the investment that has been 
made in software, and especially since the price wars of the spring of 
1977, they can point to dramatic price decreases of large system hardware 
as justification. 

The large systems role in distributed processing may be any combination 
of the following: host to a time-sharing network*, guardian of the cor- 

porate data base; as a computational resource for research and development 
users; and, host to a mammoth batch processing system. If these cate- 
gories do not sound exactly like distributed processing, it must be 
remembered that the work accomplished in a DDP system is basically no 
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different from that which was done before distributed processing - it 
is the execution mode that is different. For most users, the preferred 
approach to distributed processing is to follow a hierarchical scheme, 
with the large system as the pinnacle of a mountain of smaller computers 
and terminals. The large system has the ability to construct the complete 
corporate picture from the jigsaw of divisional and departmental pieces. 
This is the direction that this section of the presentation will follow. 

It will be shown how an effective distributed data processing system can 
be created from selective addition of equipment to the data processing 
configuration currently employed at Mare Island flaval Shipyard. 

B. PROBLEMS WITH THE CURRENT SHIPYARD MIS 

The standard Shipyard Management Information System as implemented at 
Mare Island Naval Shipyard contains a proven set of programs that five of 
the eight members of the Naval Shipyard Complex have used for thirteen 
years. The other three shipyards have utilized this version of the Ship- 
yard MIS for five years. However, there are some shortcomings to the 
system, some relatively minor, others of a more serious nature, that can 
be readily recognized. 

1 . Programs 

Current application programs are designed specifically within the 
constraints of the second generation equipment employed in the shipyard 
complex prior to the acquisition of the Honeywell 6060 equipment. These 
applications are rigidly structured with data that is intended for use 
within the Shipyard MIS processed in a batch oriented manner. Since each 
application area within the Shipyard MIS normally requires several files 
to fulfill its mission, application maintenance costs are relatively high. 
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As a result’, the data that is provided to the various users is somewhat 
behind the normal business cycle. The user does not have direct access 
to his data once it has been submitted to the Data Processing Office for 
inclusion in the Shipyard MIS; he must wait for that office to provide 
him with a printed report to be delivered at some future time. Also, 
the same data may be found incorporated into multiple applications wherever 
it is used. 

2. Internal Reports 

One of the concepts of a Shipyard Management Information System, 
as mentioned in chapter II, concerned the grouping of similar reports into 
report families based on the manner in which information is sorted. The 
major difference to be found v/ithin a report family center around whether 
the information is sorted by ship, by shop, or by work center. As an 
example, the PF-102A (Daily Force Distribution Report, Summary) and the 
PF-102B (Daily Force Distribution Report, Ship by Shift) reports are both 
generated from the Workload Forecasting Application within the Industrial 
Subsystem of the Shipyard MIS. The block diagram of the generation for 
those reports was presented in figures 12 and 13. As can be seen, these 
reports utilize the same inputs, same sorts, same control and verifica- 
tion programs, and same editing procedure. The only difference is that 
the PF-102B report will provide data concerning the total number of man- 
days expended for waterfront work per overhaul type, while the PF-102A 
report does not directly differentiate waterfront from other productive 
applications. It would be a relatively simple matter to provide another 
horizontal row for the PF-102A report in which waterfront information for 
each, shop was presented, thus eliminating one redundant report. Similar 



141 



examples of redundant reports abound throughout the Shipyard MIS report 
structure. 

3. Additional Application Requirements 

Expansion of the Shipyard MIS to include features for Quality 
Assurance, tool control, and material process control need to be imple- 
mented as discussed in chapter II. Inclusion of a Quality Assurance 
Application within the Industrial Subsystem would reduce this manual data- 
handling burden supporte dby shipyard personnel. A completely automated 
inventory and control system for expensive and portable (pilferable) 
hand tools utilized in nuclear work would assist in the reduction of tool 
"loss" and allow some of the budget currently designated for tool replace- 
ment to be deployed elsewhere. The application could be entitled "Tool 
Control" and be placed within the Material Subsystem of the Shipyard MIS. 

A material process report program should be included within the Industrial 
Material Application which updates direct material item transactions not 
only upon receipt of materia; but whenever the location status of DMI 
material changes. 

4, Greater Capabilities 

A need exists to achieve greater capabilities from the Shipyard 
Management Information System, Some of those additional capabilities 
are: the ability to obtain immediate projections as to the impacts of 

an overhaul schedule change on production schedules, manpower require- 
ments and availability, and on facility loading; automated print-out of 
job order and KEYOP instructions, material staging lists, and job material 
1 lists at the point of use and time of need; continual on-line status for 
all shop store and direct material items that are on order, in stock, or 



142 



being inspected; on-line expenditure and progress data for any ship avail- 
ability at the job order, KEYOP, and/or summary level; automated retrieval 
of applicable historical data to use for planning of new work and esti- 
mating the cost thereof, and for the forecasting of future workload; and 
an overall dynamic shipyard study capability, 

5. External Reports 

In addition to needs that are identified to serve the requirements 
of management at various levels within the shipyard, there has been a 
definite trend in increasing requirements for information on shipyard 
operations from many levels within the Federal Government. Many of the 
requirements are for one-time pieces of information; however, most of 
these one-time requirements have a habit of becoming continuing require- 
ments either for a change in an existing reporting system of for new 
reports. No relief from these trends for greater regulation from higher 
authorities and for more reporting is foreseen. Rather, the trend seems 
to be toward ever-increasing regulation. A database system that is more 
flexible than the currently employed rigid batch processing oriented 
programs is needed to provide the capability of easier response to the 
increasing regulation and reporting schemes that are predicted. 

6. Timel iness 

Although data may be delivered to the Data Processing Office early 
in a workday, it is commonly not available for managerial use until some- 
time the following workday. There are two reasons for this: first, 

routine Shipyard Management Information System processing at Mare Island 
occurs on the swing shift 0600-2400), after the normal workday is com- 
pleted, this procedure helps to ensure that all transactions that are 
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dedicated to updating a particular file are present at the time the file 
is updated; and second, guard mail or messenger pick-up of reports does 
not occur until the beginning of the next worday, this results in an 
inherent delay in transporting of reports from the Data Processing Office, 
where they originate, to the user, where they are employed. Although 
many reports are prepared daily, others are available less frequently - 
weekly, monthly, semi-annually or annually. These latter reports are 
usually of a summary nature reporting total information of a type that has 
occurred since the last similar report. However, managers still are not 
able to revidw overall summary information that they may desire until 
these summary reports are normally available, unless they wish to submit 
a special request for them. Historical data, unless managers have retained 
all of their old reports applicable to the information they may desire, 
is also not readily available in the formats necessary to meet changing 
demands from these customers. 

C. DISTRIBUTED PROCESSING AND MIS 

Many of the goals and objectives of the Shipyard Management Informa- 
tion System at Mare Island Naval Shipyard and the goals and objectives 
of a distributed data processing (DDP) system are directly related. In 
general, the goal of MINSY's MIS is to provide operational and predictive 
information to assist all levels of shipyard management in the decision- 
making process. It desires to provide information that is accurate and 
timely, in an easily understandable form that is practical, useful, and 
meaningful to these shipyard decision-making efforts. 

1 . Scope 

As events occur within the Shipyard Management Information System, 
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a distributed data processing system is able to process data concerning 
various elements of shipyard operations. Distributed data processing 
systems may be programmed to generate the wide variety of reports which 
provide operational and predictive information in either a real-time 
format, as displayed on a cathode ray tube, or present it in hard copy, 
depending on managerial requirements. Distributed data processing sys- 
tems are able to take into consideration many aspects of any industrial 
type of activity which depends upon the cycle of forecasting, planning, 
scheduling, production and evaluation. Each of these processes is given 
its processing priority and logical position within the distributed system 
by virtue of the employment and type of equipment available at each 
processing note. Feedback requirements of the Shipyard MIS are provided 
by virtue of the DDP link communications capabilities. A distributed data 
processing system is able to provide the basic tools necessary to manage 
shipyard operations with as great, or even greater, efficiency than that 
provided by the current Shipyard Management Information System. 

2. Concepts 

Several of the concepts upon which the Shipyard Management Infor- 
mation System at Mare Island Naval Shipyard is based are readily imple- 
mented by a distributed data processing system. The large volume of data 
flow experienced within the Shipyard MIS is as promptly automated and con- 
trolled by a DDP system as by any other management information system. 
Managerial philosophies of the Department of Defense and Naval Sea Systems 
Command may still be reflected in a distributed system. Since a dis- 
tributed data processing system allows for on-the-spot information format- 
ting, shipyard managers are able to design the format of the reports they 
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prefer to utilize at their processingsites , as long as standardized 
reports are still available to the remainder of the shipyard. Since 
first-line supervisors have the primary responsibi lity for quality 
inputs under a DDP system, as well as under the Shipyard MIS, this con- 
cept does not change. Local shipyard control of the development of raw 
data and report frequency is retained. Report sorting under a DDP system 
is essentially the same as under any other management information system. 

3. Adaptability 

A management information system is adaptable in that it is able 
to recognize and react rapidly to changes in technology and customer 
requirements. A distributed processing system allows for the upgrading 
of functions and performance in small increments, with low corresponding 
cost, through its extensibility characteristic. A minimum and a maximum 
size in conjunction with the number of permitted increments in order to 
achieve a future desired performance level may be specified and arranged 
for with initial system design. 

The reconfiguration capability of a distributed data processing 
system enhances this adaptability requirement in that the system can be 
dynamically altered to provide resource services directed toward satis- 
fying unique requirements. Normal operations are not significantly 
affected by virtue of these variations and the system is able to continue 
to function in its routine manner until those dedicated services are 
returned to network control. Since hardware to enhance processing is 
apportioned tfiroughout the nodes of a distributed system, technological 
innovations can be implemented at the sites that are not only most con- 
venient, but logically structured and decicated to whatever facet of 
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processing the innovation purports to enhance. This method of incorpor- 
ating technological changes results in fewer disturbances to normal opera- 
tions since the entire processing system does not have to be shut down 
in order to install the change. It is also physically easier, normally, 
to implement a change to a processing system at a satellite node than 
it is at a central processing facility. 

4. Integration of the MIS Functional Levels 

Integration of the six levels of a management information system 
is enhanced by a distributed data processing system. Although processing 
nodes may be located at sites dedicated to any one of the six MIS levels 
of planning, forecasting, control, modeling, computing, or data adminis- 
tration, the network operating system resident within the distributed 
data processing system ensures that the jargons, techniques and data 
employed by those specialists are integrated into the total system con- 
figuration allowing for achievement of the overall objectives of the Ship- 
yard MIS in the most expeditious manner. Each functional level of the MIS 
is able to exploit the various resources available at the other functional 
levels within the Shipyard MIS through the capabilities of the NOS in 
order to attain their common goal. 

5, Primacy of Managerial Decisions 

Retention of the primacy of managerial decisions within the Ship- 
yard Management Information System is intensified in a distributed data 
processing system. Information is available to managerial personnel soon 
[ after it is entered into the system. Programs resident within the dis- 
tributed system may be dedicated to the tedious work of data searching, 
calculating, information summarizing and data comparisons. These 
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facilities of the system will free the decision-makers to: make appro- 

priate conclusions from the recognition of problem areas; generate 
relevant assumptions; define criteria; and, evaluate alternatives. Those 
processes, in turn, permit the same managers to perform the creative work 
of management, decision making. The distributed data processing system 
is a tool by which managers would be allowed to concentrate on the neces- 
sary decision making practices, not the processes by which the information 
was presented, 

D. EQUIPMENT ACQUISITION 

Regulations originating from Federal agencies control every phase of 
a computer's life-cycle in the government - from the initial planning 
stages, through acquisition of the system, to the eventual disposal of 
the unit. These regulations apply not only to the actual computer, but 
also to peripheral devices such as disc units and terminals. No less 
than one public law, eight Office of Management and Budget circulars, 
forty-four Federal Information and Processing Standards, twenty-eight 
Government Accounting Office reports and studies, and a multitude of 
other directives and regulations have been published to guide the Federal 
automatic data processing manager in the acquisition of general purpose, 
automatic data processing equipment CADPE) in the Navy, 

Without elaborating on the total procurement process, from consider- 
ing only the volumes of regulations concerned, it is obvious that to simply 
follow the rules of acquistion is a time-consuming and complex process. 

In addition to the guidance provided from the previously listed regula- 
tions, each Federal agency has developed its own implementing directives 
and instructions to insure compliance with that multitude or rules and 
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regulations. Often, rather than clarifying or attempting to simplify 
procedures, the local agency regulations only serve to confuse and 
complicate the procurement process. As a result, many activities having 
a real requirement for a relatively minor piece of computer hardware 
become confused and resentful when faced with that tangled array of rules 
and regulations. For a large computer installation project, it is esti- 
mated that up to four years are required from concept formulation until 
the commencement of the actual acquisition. Depending on the complexity 
of the system, an additional nine months to two years is then required 
to conduct the actual acquisition. This results in a total cycle time 
of approximately five to six years from the concept formulation stage 
until completion of the acquisition. With six to eight years being the 
generally accepted figure for the time between successive computer 
generations, equipment is often out-of-date before a new system becomes 
operational. A Honeywell representative has estimated that the Federal 
Government process takes four times as long as a civilian commercial 
procurement. Peter F. McCloskey, a former president of the Computers and 
Business Equipment Manufacturers Association, stated that the Federal 
acquisition process ". . frequently results in procurement of technology 
that is obsolete because of the time it takes to implement purchase." 

One estimate has claimed that, in 1977, sixty-eight percent of the Depart 
ment of Defense ADPE inventory was obsolete, as compared to a thirty-five 
percent figure for private industry [22]. 

It is not the purpose of this presentation to describe the detailed 
procedures required for the acquisition of equipment required to support 
the implementation of a distributed data processing system at Mare Island 
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Naval Shipyard. It is acknowledged that the paperwork and justifica- 
tions required for such an acquisition are beyond the scope of the basic 
justifications presented: how distributed data processing supports the 

goals and objectives of the Shipyard MIS; how DDP is able to alleviate 
some of the shortcomings within the Shipyard MIS: and, how distributed 

data processing is able to perform the required management information 
system functions of the shipyard in an efficient and responsive manner. 
Much more detailed analyses would be required, including cost specifi- 
cations and demonstrable savings, prior to any consideration being given 
to the acquisition of any of this type of equipment. For purposes of this 
presentation, it will be assumed that the decision to "go distributed" 
has been made by proper authority. It will also be assumed that the 
implementation of the distributed system is to be accomplished using 
available Honeywell devices, incorporating them in the 6060 system cur- 
rently installed at Mare Island wherever possible. 

E. PERSONNEL PREPARATION 

Most employees, including supervisors and managers, are reluctant to 
see major changes made in their departmental organization and work flow. 
Knowledge about an operation that has been built up over a long time 
period breeds familiarity and confidence. Change brings the unknown and 
associated apprehension based on a lack of knowledge and confidence in 
that unknown. To avoid being unprepared, and to overcome the apprehen- 
sion of personnel, the implementation of distributed processing must be 
approached in a planned and orderly fashion.. There are several approaches 
available to develop policies and prepare personnel for, and to improve 
the acceptance of, DDP within the Data Processing Office and Mare Island 
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Naval Shipyard. 

1 . Education 

An important initial step is to be certain that affected parties 
within the organization have the same understanding of what distributed 
data processing means and what it can do for the organization. Often 
customers and data processing professionals are educated by a vendor 
advertisement, a news review of limited scope, or a biased magazine 
article. These may have conveyed misconceptions about OOP technologies 
and capabilities which may have curtailed its general acceptance and 
make it difficult for the individual to objectively evaluate OOP use in 
a variety of different applications. On the other hand, different mis- 
conceptions may have given the potential user unrealistic expectations 
of OOP. 

The best way to eliminate this problem of misconception is to 
educate all parties concerned with the operation of the Data Processing 
Office. Any number of educational methods, or combinations of methods 
may be employed [23]. These methods are outlined in figure 18 with the 
program, source, benefits, and disadvantages of each summarized. The use 
of this awareness education in distributed. data processing can give all 
attendees a common reference point. It should not be expected, however, 
that such education will force everyone to think alike. If most of the 
people that are involved in the implementation of DDP have been through 
the same educational program, the professional data processing staff is 
able to use that material as a basic for building its rationale for a 
specific configuration to be employed within the shipyard. 

In addition to the basic orientation course provided to all 
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Figure 18 EDUCATIONAL METHODS 
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interested parties, data processing professional staff members that are 
to be responsible for the total implementation and operation of the 
distributed processing system within Mare Island Maval Shipyard will 
require more detailed knowledge of DDP in general, and the Honeyv^ell 
Information System as it includes a distributed data processing format, 
in particular. These subjects and level of knowledge desired are sum- 
marized in figure 19. In the education of the data processing staff, 
information may have to be sought from a number of different sources since 
no one source is capable of providing the complete sphere of information 
required. These sources should be selected, used, and balanced to suit 
the needs of the staff. They include: professional seminars; hardware 

vendor training; professional and vendor literature; visits to sites where 
distributed processing is in use; attendance at relevant professional 
conferences; and, self-study materials. 

2. Database Administrator 

The database administrator (DBA) is an organization's leader in 
the planning, design, development, implementation, testing, documentation, 
operation and maintenance of the entire database environment. The 
functional orientation of the database administrator is usually character- 
ized as both technical and administrative in nature. There is also a 
promotional aspect inherently present in that the DBA represents database 
administration concepts to all participants and coordinates all database 
activities among managers, analysts, systems and applications program- 
mers, and, of course, the users. Because database administration activ- 
ities often impact across organizational boundaries, the DBA position 
becomes sensitive, and the prudent database administrator must be shrewd 
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Figure 19 
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in discerning jurisdictional questions and conflicting mission require- 
ments. 

a. Database Adminstration Concepts 

Database administration, by necessity, encompasses all of 
the technical and managerial activities required for the organizing, 
maintaining, and directing of the database environments [24].. A data- 
base environment consits of the database itself, which may include non- 
automated as well as automated information, the database administrator, 
who will actually manage this environment, the software tools used in 
database administration and data processing, and the users of the 
database. The main goals of database administration are to: optimize 

usage of data in a shared database environment; incorporate a systematic 
methodology for the centralized management and control of data resources; 
and, balance any conflicting objectives with respect to the parent organi- 
zation's mission and the overall economy of information handling. 

Several key requirements for effective database administration 
exist as follows: senior management must be strongly committed to the 

concept and support it fully; the database administration staff must be 
technically competent; and, there should be team participation in the 
database concept by the DBA, the technical staff, senior management, and 
the users. Efficient database administration can provide several signi- 
ficant advantages: the actual database can be better managed especially 

in the context of centralization of database control and the sharing of 
resources; data independence will be realized by virtue of controlled 
definition, design and implementation of the database; data redundancy 
and inconsistency will be reduced by the assessment and prioritization of 
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conflicting requirements; data integrity will be realized when standard- 
ization of usage and enforced security regulations are employed; and, 
increased responsiveness to the various user communities can result 
from the better controlled and more up-to-date information that an 
efficiently administered database will provide. 

b. Database Administrative Functions 

The following list, although not exhaustive, presents some 
of the basic functions of a database administrator. The DBA should be 
able to identify and define common data elements. This recognition 
needs to include the relationship between data elements and other com- 
ponents of the system such as programs and files. These conceptual defi- 
nitions should be based on a clear understanding of each user's require- 
ments as well as the needs of the overall parent organization. Whenever 
possible, the DBA needs to use a data definition language to define and 
structure the database. It is also within the realm of DBA responsibility 
to review and monitor data standards. Should the need arise for dynamic 
alteration of the database, then the DBA must initiate it, redefining 
the database, or any part of it, with a minimum of disruption and incon- 
venience to the users. 

The database integrity function is related to the DBA's responsi- 
bility for the correctness and accuracy contained within the database. 

This can be achieved through the use of validation checks, stringent 
access procedures, periodic data dumps, backup and recovery procedures, 
as well as well-defined audit procedures. The relationship between the 
DBA and database security is a cursory one. He must, however, ensure 
that steps have been taken to guard against unauthorized access to the 
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database for purposes of unauthorized update, copying, removal or 
destruction of any part of the database. Often security and integrity 
requirements are combined into one software system which will implement 
procedures designed to simultaneously perform both functions. 

The database administrator must be held responsible for the 
continued well-being of the database. In this capacity, it is his respon- 
sibility to maintain and update database definitions and documentation 

including the data element dictionary. If database performance monitoring 

$ 

and evaluation activities indicate that the database is no longer effective 
or efficient in its present configuration, then redefinition, redesign, 
or restructuring activities may be indicated. It is the responsibility 
of the DBA to advise higher authority when this requirement manifests 
itself, and to ensure that minimum disruption of user services result. 

The database administrator should interpret and administer 
upper level management policies as they are related to the database, and 
define rules of use and access constraints for the database. Addition- 
ally, the DBA should be held accountable for review and approval of new 
data definitions and the enforcement of data standards. These enforce- 
ment activities include: determination of compliance with established 

standard usages; development of database content, organization and storage 
control procedures; and, responsibility for access control and security 
of the database as previously mentioned. 

c. Benefits of the Database Administrator 

Adoption and utilization of database administrator concepts 
as vested in the database administrator dramatically improve the effec- 
tive ness of an organization's data processing efforts since a focal 
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point IS firmly established for the responsibility, management, and 
control of total data resources. Some of the major advantages to upper 
management of having a positive database administration function, as 
implemented by a strong database administrator follow. 

The controlled database environment that is managed by the 
database administrator helps to assure efficient performance and increased 
operational reliability in the manipulation of data. This can promote 
data integrity, encourage standard data usages, enforce security safe- 
guards, ensure controlled accessibility, and balance conflicting require- 
ments. Application of the multiple tools that are part of the database 
administrator's tool chest can improve the utilization of the database. 

The uniform database monitoring that is accomplished by the 
database administrator and his staff can facilitate a total organizational 
overview of all of the data resources. It can help in managing the 
growth and changes that occur in the database by ensuring that such growth 
is antipated and controlled. The optimization of database utilization 
can result from the enforcement of shared data resources. Any required 
reorganization, redesign, and restructuring activities associated with 
the database can be performed centrally for the entire organization 
simultaneously. 

3. Personnel Reorganization 

Since database administration is primarily a human function, its 
influence is affected by its placement within the organizational hier- 
archy, The variety of opinions with respect to the optimal residence 
of a DBA leads one to conclude that there is really no perfect organiza- 
tional placement for a database administrator. Each system‘'s environment 
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operates with distinct organizational characteri sties and the decision 
as to where to place the DBA nearly always involves tradeoffs. 

Three organizational entities with which the DBA must contend 
are: computer operations, which is concerned with operating equipment; 

computer system analysis, which is concerned with the analysis and 
design of user applications; and, the users, who are concerned with 
ease of access to, and completeness of, the database. Personnel in each 
of these areas primarily consider their own interests and make the 
placement of the DBA within any of these organizational units a question- 
able policy. The solution offered is to place the database administrator 
in a staff position, reporting directly to the highest manager responsible 
for data processing within the organization. 

The organization of the Data Processing Office at Mare Island 
Naval Shipyard indicates a logical location for the placement of the 
DBA within that hierarchy. Inserting the title of "Database Administra- 
tion Division" and a functional code of 114, the DBA will acquire the 
appropriate organizational niche. The pay grade of the data base admin- 
istrator himself should be equal to that of the Operation Division Head, 
GS-12 (Government Standard level twelve). Staffing of the Database 
Administration Division is accomplished by employing two GS-9s and four 
GS-7s as heads and staff members of the "Technical Branch" (Code 114,1) 
and "Administrative Branch" (Code 114,2) respectively. The recommended 
reorganization of Mare Island's Data Processing Office is summarized in 
figure 20, 

The keypunch unit currently employs two shift supervisors, 6S-6, 
three team leaders, GS-5, and twenty-three data transcribers , GS-3/4. 
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Figure 20 DATA PROCESSING OFFICE - REORGANIZED 
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These personnel are distributed roughly evenly between the daytime and 
swing-shift operating periods. With the implementation of the automated 
inputs associated with distributed processing, the following reorganiza- 
tion of these personnel would occur; both supervisors and one leader 
would become computer operators or technicians, one per shift; and, 
seventeen data transcribers would be transferred to the distributed data 
processing sites and retitled "Data Input Technician", thus eliminating 
the need for the distributed processing sites to provide an individual 
dedicated solely to keyboard operations. The remaining six data trans- 
cribers and two leaders would retain their present capacities since some 
keypunch requirements would undoubtedly remain. No other reorganization 
of the Data Processing Office is needed since the requirements and 
functions of the overall Shipyard Management Information System would not 
change under a DDP configuration. 

F. DATA BASE MANAGEMENT SYSTEM 

The responsibility of defining the content and structure of the data 
base and assigning data access and modification rights belongs to the 
database administrator. The data base management system (DBMS) is that 
element within the tool chest of the DBA that provides an integrated 
source of data for multiple users, while presenting different views of 
the data to different users. It can be characterized as generalized 
software which provides a single flexible facility for accommodating 
different data files and operations, while demanding less programming 
effort than conventional programming languages. Since the general orien- 
tation of this chapter has been toward maintaining compatibility with 
the Honeywell 6060 Information System currently in use at the Mare Island 
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Naval Shipyard, the Honeywell Integrated Data Store/II (IDS/II) data 
base management system will be described as the system of preference for 
employment in the distributed data processing system. 

1 . IDS/II Description 

Honeywell's IDS/II is a generalized database management system 
which operates on the CALL level, with programs written in COBAL-74, 
and permits users to create, maintain and retrieve data [25], On-line 
users interact with IDS/II through an interactive language which pro- 
vides a wide variety of data manipulation verbs, IDS/II will run on the 
Honeywell Series 6000 Information System, of which MINSY’s 6060 is a 
member, as modified by an extended instruction set. Minimum main storage 
for IDS/II is 128K words, which includes the storage requirements for the 
6C0S operating system. 

IDS/II employs a linked list using both forward and backward 
pointers and hierarchically structured files consisting of fixed and 
variable length records. When declaring the data base, users may 
specify that it be logically constructed as network, hierarchical, chained 
or a combination of these. The physical organization may be sequential, 
indexed-sequential (ISAM), or random. IDS/II maintains this separate 
physical and logical view of the data structures to allow record and data 
placement on the storage media to be essentially independent of the asso- 
ciations and relationships among those records. Facilities are provided 
for storing and locating records directly, through a key field embedded 
in each record, or relatively through its current location in its chain. 
Both hierarchical and network data structures are supported as a by-product 
of the record linking and chaining techniques. 
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A high-level of data security is offered by IDS/II which allows 
users to assign passv/ords down to the field level. Data integrity is 
also to the field level which enables changes to be made to the data 
base without recompiling the applications that may employ them. Fur- 
ther data integrity is enhanced through systems journalization, automatic 
restart, and automatic recovery capabilities. 

2. Data Base Structure 

An Integrated Data Store/II data base is described in terms of 
three main types of entities: a schema [global ) definition of all data 

structures in the data base, their logical associations and interrela- 
tions, and their primary storage and retrieval attributes; one or more 
subschemas or definitions of subsets of the schema that are accessible 
by application programs; and, area definitions that describe the mapping 
of the schema and subschema data structures to physical data sets. At 
the elemental data levels, an IDS/II data base comprises records and 
sets. A record is a named collection of data items indicating both the 
primary access method through which record storage and retrieval will be 
done, and the record occurrence to area mapping attributes. A set is a 
named collection of records which have a logical relationship. One 
record-type is defined as a set OWNER, while a second record-type is 
defined as a set MEMBER. Set relationships can be built to form hier- 
archies, simple and complex networks, and cycles. Structural linkages of 
set members can be used to provide secondary access paths to records. 

Primary access paths to a given record are a function of its 
LOCATION MODE, the method by which ft is entered onto the data base. 
Records are first stored in and retrieved from a data file, each record 
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is then assigned a unique data base key which represents its storage 
location relative to the start of the data base. Each record defined 
for the schema must describe its location mode by either a DIRECT, CALC, 
or VIA set-name. Records defined as having a DIRECT location mode are 
assigned a data base key by either the Data Base Control System (DBCS) 
or the user. The user to DBCS interface is through a parameter in a user 
work area. CALC location mode records are located by virtue of a trans- 
form algorithm that uses values contained in specified data fields of a 
record to produce a header address. VIA set-name location mode records 
are stored as close as possible to their owner record within the data 
base. 

3. Data Description 

Data description is effected through three media; schema and 
subschema Data Definition Languages (DDL) and a Device Media Control 
Language (DMCL). The schema DDL describes data base content such as 
physical record structure, access methods, privacy constraints, data 
items and their attributes, and set relationships; the schema thus 
defines the global data base. The subschma DDL defines subsets of 
this global data base and provides the user interface with the schema. 

The DMCL describes the storage space areas and their page sizes. Each 
of these is to be controlled, maintained, and implemented by the database 
administrator. 

The DBA implements each of these elements separately from any 
intended using program. The schema is developed first graphically, then 
translated into a series of global DDL statements, compiled, and entered 
into a data element dictionary and schema file. A similar sequence is 
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followed for the DMCL. Subschemas are developed for the using programs, 
compiled, validated against the schema, and entered into a validated 
subschema file. Associated with all definitions (schema, subschema, and 
area) are privacy locks which can be further strengthened through pass- 
word controls established at the general comprehensive operating system 
and file maintenance supervisor levels, 

4, Data Retrieval 

Data accessing is through a subschema declarative that is incor- 
porated into the data division of a using program'^s COBOL-74 source deck. 
During compilation, a user work area is created and the subschema linkage 
data is compiled into object code. At execution time, a check is made to 
determine if the proper subschema has been compiled, validated, and trans- 
lated in logical sequence. The using program is then linked with the 
subschema object file, and necessary control references are provided. 
During processing, data pages are read into internal buffer regions, 
which may be either pooled or distributed on an area basis. The subschema 
may declare that the data items of any record format be ordered in a 
fashion convenient to the using program. The data content itself may 
be transformed to a format convenient to the using program through ENCODE 
and DECODE functions. A full word of binary data within the data base 
will thus be represented to various using programs as packed decimal or 
ASCII character string data. 

Communication between the using program and the Data Base Control 
System (DBCS) is accomplished through various registers and flags, and 
through the system's Data Manipulation Language (DML). At any point 
during processing, the user is able to receive the current status of all 
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database functions relative to the program. He will know which area is 
current, which set and record name is current, and the status of a 
requested DML function. Data base keys are related through communica- 
tions registers and privacy locks supplied to the DBCS through a defined 
register. Privacy locks may be declared to disallow access to a record, 
or to disallow specific DML functions for a subschema unless the lock's 
key is supplied. Records may be retrieved, stored, inserted, removed 
or erased from a set if the proper privacy locks have been cleared. 

A FIND is included in the data manipulation language which per- 
mits record-selection expressions based on structural conditions exist- 
ing in the data base such as find next-in-path, and find record-name 
within a set or area. Other IDS/II interactive data manipulation verbs 
include: ACCEPT, CONNECT, DISCONNECT, ERASE, FINISH, GET, LIST, MODIFY, 

MOVE, READY, REPEAT, SET, STORE, and USE. The ACCEPT and SET verbs pro- 
vide data base key manipulations. FINISH and READY provide area prepara- 
tion statements. USE invokes any embedded data procedures in DBCS required 
for a current operation. The remainder of the verbs perform record and 
data manipulative functions. Boolean, comparative, or relational opera- 
tions must be performed through host facilities of COBOL-74. 

G. EQUIPMENT ORGANIZATION 

Previous portions of this chapter have delineated problems associated 
with the current Shipyard Management Information System as it is employed 
at Mare Island Naval Shipyard. Compatibilities which exist between dis- 
tributed data processing and MIS philosophies have been described which 
have led to the implication that DDP fulfills MIS managerial requirements. 
The need for, and benefits of, a database administrator to be responsible 
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for the management of the data base have also been presented. The method 
by which personnel of the Data Processing Office will be prepared for 
the new processing procedure and the relatively minor reorganization 
necessary within this office have also been related. For sake of brevity, 
it has been assumed that permission has been received to implement dis- 
tributed data processing and to acquire DDP equipment that is compatible 
with the Honeywell 6060 information system. What remains, then, is to 
describe the equipment organization that will be required to construct 
a distributed data processing system at Mare Island Naval Shipyard. 

1 . Network Configuration 

There are three commonly used methods of distributing the data 
base to satisfy the requirements of a distributed management informa- 
tion system [26]. These processing configurations are known as star, 
hierarchical, and ring networking. Each of these methods has inherent 
advantages and disadvantages. However, since this analysis is tasked 
with retaining the 6060 system as a basis for distributed extensions, 
the overall network configuration to be implemented is also constrained 
by this requirement. 

a. Hierarchical Configuration 

The hierarchical configuration is a viable means of implement- 
ing the data base. Within this configuration, the system consists of a 
host computer followed by an arrangement of lesser machines until a ter- 
minal level is rached. The primary advantage of a hierarchical config- 
uration is that it provides distributed computing power. This 
configuration is also quite suitable for implementing heterogeneous nodal 
processing systems. Although there are no inherently obvious major 
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disadvantages to this configuration technique, one characteristic elimin- 
ates it from further consideration: since a desired theme is system 

homogeneity and standardization, and since heterogeneous nodes require 
additional translation processes to make them interact smoothly with the 
overall system, this becomes a future development for MINSY and not to 
be considered here. 

b. Ring Configuration 

A ring configuration is the ideal of the distributed proces- 
sing purist. All data is distributed; no redundant data exists; and, 
nodes share data through a common link. Ring configuration provides 
autonomous processing nodes without redundant data, which is ideal as 
long as the system remains sound. If a break occurs in the ring, no 
backup is available unless a redundant ring is installed, resulting in 
demise of the entire system, especially if the failed node holds an 
important portion of the data base. The DBA must devise an updatable 
directory to identify where specific information is located around the 
ring and then place it where it is accessible to all nodes. A solution 
to both problems is to connect the processing nodes to a central host 
which could contain both the directory and the backup data base. This 
leads to the configuration of choice, the star configuration. 

c. Star Configuration 

The star configuration is similar to the commonly used 
centralized data base concept. This system consists of: a host computer 

that contains a central data base, controllers, and the common data 
access method; and, node processors consisting of minicomputers and 
relevant portions of the distributed data base. This centralized system 
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provides tight control over data, ensures data security, provides a common 
file accessing technique, and provides a common data base logical struc- 
ture. 

A major problem associated with this configuration is data unavail- 
ability due to file usage or line loading. A way of overcoming this is to 
distribute copies of the appropriate data to the concerned processing 
nodes thus eliminating delays due to line loading or use by other nodes. 
This does result in data redundancy and some loss of control in terms 
of directory maintenance, however, the benefits of backup and share- 
ability offset those disadvantages. By retaining a master copy of the 
data base locally, the database administrator is able to exercise control 
over its content, organization, and security. Redundancy enhances 
backup and shareability since the central system is able to continue 
servicing other nodes requiring data from a failed node. 

If the failure of a node is due only to a communications break- 
down, the node will continue to service local users. This continued 
processing does compromise the integrity of the data at the central site 
which is only as current as the last input from the nodes. A highly 
dynamic MIS cannot tolerate a prolonged nodal failure. A solution is to 
permit normal processing to be on a query-only basis, where not all data 
would be as current as possible, with all updating done during off-hours. 
Since batch, processing is currently handled this way at MINSY, no major 
changes in operating procedures would be required to implement this 
technique. 

2, Honeywell Level -6 Minicomputer 

A primary ingredient for distributed processing, alluded to 
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throughout this presentation, is the implementation of computing power 
and data storage for a specific application within the Shipyard MIS at 
a dedicated processing node. This node must be able to interface with 
the host Honeywell 6060 system through the installed DATAMET 355 Front- 
End Network Processor. The Honeywell Level -6 Minicomputer family is 
suited to fulfill those requirements. Level-6 architecture is based on 
a twenty-four-bit-wide universal bus called the Megabus. The CPU attaches 
directly to the Megabus using controller boards, which give Level-6 a 
modular architecture. Up to four device or memory pacs, a Honeywell term 
for dedicated modules, fit on one controller board. Since the memory and 
peripherals are attached to the sane bus, all data is transferred using 
direct memory access [27]. 

a. Central Processor 

All Level -6 processors use a microprogrammed architecture 
with a transistor-to-transistor bipolar logic (TTL) and a sixteen bit 
word length. Standard features for Level -6 processors include sixty-four 
firmware-controlled vectored priority interrupts, extended instruction 
sets, flexible word lengths, hardware multiply and divide, a real-time 
clock, a ROM-based boostrap loader, and ROM-based diagnostics. 

Most hardware registers are sixteen bits in length except for 
the mode registers which are eight bits long. Within this framework, 
the CPU can process double words (thirty-two bits), words (sixteen bits), 
bytes (eight bits) or single bits. Floating point values can be two or 
four words. The Level -6 uses tv/o types of data: signed data is used in 

arithmetic operations; unsigned data is ued for logical quantities, addres- 
ses, or ASCII characters. Unsigned data is expressed in hexadecimal 
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notation while signed data is represented in two's complement notation. 

The basic set of 106 instructions include: bit instructions 

for testing, resetting, and complementing addressed bits; byte instruc- 
tions for logical arithmetic operations; and word and multiple word 
instructions for handling data of variable size. Single and double- 
operand instructions manipulate the data in registers and memory; 
short-value immediate instructions manipulate data in the general regi- 
sters. There are thirty-two branch and branch-on-indicator instructions, 
twelve shift instructions, three I/O instructions, and fifteen generic 
instructions. 

Sixty-four multiple vector interrupt levels can be priority 
programmed by the user and implemented by firmware through the Megabus. 
Interrupt levels for each controller can be dynamically set by software 
before each job or before each peripheral instruction sequence. The CPU 
determines from the assigned interrupt level whether a board can inter- 
rupt, and the order in which interrupts will be honored. The processor 
can receive an interrupt request at any time, including the time between 
the two cycles of a read operation. However, the interrupt is not proces- 
sed until the instruction has been completed, 
b. I/O Control 

All input and output for Level-6 minicomputers occur over the 
Megabus using direct memory access (DMA) transfers. The Megabus is an 
asynchronous, bidirectional bus with a transfer rate of six mega-bytes per 
second and a cycle time of 300 nanoseconds. The bus is fast enough to 
allow many I/O operations to be multiplexed. Multiple I/O units can multi- 
plex on a word basis to the same memory unit as long as the combined data 
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transfer rates do not exceed the maximum memory transfer rate of 1.1 
million words per second. Three intelligent peripheral controllers 
are provided: the Multiple Device Controller, Mass Storage Controller, 

and Magnetic Tape Controller. A general -purpose DMA interface for user 
logic is also present. 

c. Peripherals 

Honeywell supplies a broad range of low-speed peripherals 
and high-speed units in addition to a number of terminals. All peri- 
pherals interface through device pacs [modules) on the individual con- 
troller boards which connect to the Megabus. Level -6 's low-speed devices 
(card readers) card punchers, serial and line printers) are supported 
by the Level -6 Operating System and require device pacs that fit on the 
Multiple Device Controller. High-speed peripherals are also supported 
by the Level-6 Operating System; magnetic tape drives require a device 
pac for each drive and one magnetic tape controller for every four drives 
up to four large disc packs are supported by one device pac and one Mass 
Storage Controller. Teletype-compatible CRTs and teleprinters are sup- 
ported by the GCOS-6 software and interface to the Megabus through the 
Multiple Device Controller or through the Multiline Communications Proces 
sor. 

d. Data Communications 

The Multiline Communications Processor (MLCP) is the hard- 
ware basis to Level-6 data communication capabilities. The MLCP board 
has a microprocessor with 3,072 words of RAM that the user can program 
for his own line handling and protocols with the help of MLCP software. 
The on-board microprocessor delimits the data stream and offloads the CPU 
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of character generation, error detection, and the clock-check function. 
Maximum throughput is twenty-four thousand bytes per-second. The MLCP 
holds up to four line adapters of any mix of synchronous, asynchronous, 
broadband, or current-loop connection communication pacs. 

MLCP software is supported under the Honeywell General Com- 
prehensive Operating System. GCOS-6 supports synchronous and asynchro- 
nous protocols, and communications features including a subset of the 
IBM 2780 bi -synchronous protocol. Two communications utilities are 
available under GCOS-6: Data Entry Facility (DEF) is a data-entry forms 

package; and. Remote Batch Facility (RBF) allows the Level-6 processor 
to be used as a remote batch station for the host processor, 
e. Software 

Honeywell provided software for the family of Level -6 mini- 
computers includes operating systems, language processors and a wide 
range of utilities. The GCOS-6 operating systems are multi-tasking, 
multi-user disk-based operating systems. Source and object text programs 
of the Basic Executive System (BES) can be run under GCOS-6. Five major 
languages are available for the Level-6: assembler with macro preproces- 

sor, FORTRAN, COBOL, BASIC, and RPG. GCOS-6 and BES operating systems 
utilities include the options of Sort/Merge, DEF, and RBF. 

0 ). Operating System. As a full diskette-based real-time 

software system, GCOS-6 has extensive executive, file management, and 
communications facilities, and a wide complement of development software. 
The GCOS-6 executive concurrently executes one batch stream (program 
development or other user application) and a number of on-line user 
application job steams limited only by the amount of available memory. 
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Batch applications can be rolled out to a mass storage device in order 
to obtain more memory for on-line applications. 

Operators communicate with the operating system through 
four control languages; System Generation, Execution Control, Operator 
Control, and Monitor Control. The System Generation Language is used 
to develop system generation directives from a set of directives supplied 
with the operating system. The Execution Control Language controls all 
task groups, enables users to submit batch requests, handles file-related 
functions, and handles the execution of all utilities. The Operator 
Control Language allows the operator to control on-line task groups, 
batch streams, and device assignment. Macro calls of the Monitor Control 
Language allow the user to perform monitor functions with an assembler 
language program. 

The GCOS-6 tree-structured file system provides different 
file systems for each of the supported I/O devices. It provides four 
file organizations for discs - sequential, relative, indexed, and fixed- 
relative. Sequential access is provided for magnetic tape, communica- 
tions, and all unit record devices. Files can be accessed by COBOL, 
FORTRAN, RPG, or assembler language statements. GCOS-6 requires a CPU 
with thirty-tv/o thousand words of memory, one cartridge disk unit, or 
four diskettes, and one terminal* 

(2) Language Processor * GCOS-6 (entry level) COBOL is based 
on ANSI COBOL-74 standards. This COBOL level requires thirty-two thou- 
sand words of memory. Extensions include support of file handling for 
sequential, relative, and indexed files, three-dimensional tables, CALL 
and CANCEL capability, DISPLAY and COMPARE data, full American National 
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Standard editing, and twenty-one additional verbs. GCOS-6 (intermediate) 
COBOL, also based on ANSI COBOL-74 standards, provides facilities for 
reentrant programs, packed decimal and thirty-two-bit signed binary data 
types, and the callable Sort/Merge utility. Even though other languages 
are supported by GCOS-6, only the COBOL language has been further ampli- 
fied since that is the language of use at Mare Island^s Data Processing 
Center. 

(3) Utilities . The Sort/Merge utility for GCOS-6 features 
up to sixteen sort-key files of ASCII or numeric data; the output sequence 
is based on ascending or descending sequence by key: a temporary work 

file can be created and automatically deleted later; the BES Sort 
accepts control fields of up to eight keys per record with a maximum single 
key size of 356 bytes and a maximum record size of 512 bytes. The Data 
Entry Facility of the GCOS-6 utility for form creation supports up to 
twelve terminals and up to six line or serial printers; the DEF package 
1 is able to execute simultaneously with the GCOS operating system. The 
Remote Batch utility allows the Level -6 to be used as a remote batch ter- 

I 

[ minal to the host computer while still performing its own on-line proces- 

' sing; the host computer is interfaced by Remote Computer Interface 

protocols. 

3. DPP System Architecture 

The architecture of the distributed data base system at Mare 
; Island Naval Shipyard must closely resemble the representative DDP 

system as presented earlier in figure 3, of chapter I, and as constrained 
by the 6060 system already in use. The Honeywell 6060 system is to remain 
as the host processor and contain the central CPU. The central data base 
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remains resident within MINSY's Data Processing Center. The Integrated 
Data Store/I I database management system is to be incorporated into the 
overall system* The DATANET 355 Front-End Network Processor provides 
a controlling function for the Level -6 Minicomputers that are to be 
installed as node processors. Each. Level-6 site contains the data base 
and full rnage of peripherals relevant to that particular subsystem or 
application mode that the node is dedicated to serve. Figure 21 por- 
trays this overall system. 

Whether or not a location that is a candidate site for a distri- 
buted node receives a Level-6 Minicomputer with its full range of dedi- 
cated databases, input and query permissions as well as peripherals, a 
CRT and keyboard for query-only, or a CRT and keyboard including input 
as well as query permissions, is dependent upon: its relative importance 

in the shipyard organizational hierarchy; the amount of information it 
requires to efficiently perform its function; the number of transactions 
it generates; and, the volume of data that is inherent to its functional 
application within the Shipyard MIS. Initially, the following six 
functional areas within MINSY should contain a Level-6 Minicomputer with 
its full range of databases, input and query permissions, as well as 
peripherals; the Planning, Production, Supply, Comptroller, and Admin- 
istrative Departments, and the Data Processing Office. Offices that will 
be allowed query and input functions will be connected to the relevant 
Level-6 application they serve. Inputs will be allowed only to the files 
for which a specific terminal is responsible. Query-only terminals are 
to be connected to the specific Level-6 function to which they refer, but 
may access the central data base and other nodes for information that is 
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Figure 21 DPP SYSTEM ARCHITECTURE 
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required in the performance of the duties of the area in which they are 
resident. These initial connections are summarized in figure 22. It 
will be the responsibility of the requesting department head in liaison 
with the Management Engineering Office and the Database Administrator 
to decide on the placement of Level-6 Minicomputers and terminals 
throughout Mare Island Naval Shipyard. 
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Figure 22 DPP SITES 
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